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ABSTRACT 


Program  Managers  (PMs)  need  insight  into  the  high-risk  and  high-cost  elements 
of  their  programs  to  effectively  manage  them.  The  Department  of  Defense  (DoD)  has 
adopted  several  acquisition  reform  initiatives  in  order  to  become  a  smarter,  more 
efficient,  and  more  responsive  buyer  of  goods  and  services  that  meet  our  warfighter’s 
needs.  DoD  Regulation  5000.2-R  requires  PMs  to  tailor  a  work  breakdown  structure 
(WBS)  for  each  program  using  the  guidance  in  Military-Handbook-881  (MIL-HDBK- 
881),  "DoD  Handbook  -  Work  Breakdown  Structure."  This  research  concludes  that  a 
WBS  structured  in  accordance  with  MIL-HDB-881  can  significantly  impede 
implementation  of  DoD  acquisition  reform  initiatives.  It  does  not  adequately  identify  the 
key  products  and  processes  essential  for  program  success.  An  alternate  method  of 
constructing  a  WBS  was  developed  which  better  identifies  and  differentiates  key 
products  and  processes.  This  research  concludes  that  the  alternate  WBS  has  the  potential 
to  significantly  facilitate  implementation  of  recent  DoD  acquisition  reform  initiatives,  as 
well  as  the  potential  to  provide  PMs  greater  visibility  and  early  identification  of  cost, 
schedule,  performance,  and  risk  issues  using  an  Earned  Value  Management  System 
(EVSM). 
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I. 


INTRODUCTION 


A.  PURPOSE 

During  the  past  decade,  defense  acquisition  reform  has 
been  very  intense.  The  Department  of  Defense  (DoD)  has 
adopted  several  acquisition  reform  initiatives  in  order  to 
be  a  smarter,  more  efficient,  and  more  responsive  buyer  of 
goods  and' services  that  meet  our  warfighters'  needs.  The 
effectiveness  of  those  acquisition  reform  initiatives  may  be 
dependent  on  the  program  and  contract  work  breakdown 
structure  (WBS) .  DoD  Regulation  5000. 2-R,  "Mandatory 
Procedures  for  Major  Defense  Acquisition  Programs  (MDAPS) 
and  Major  Automated  Information  System  (MAIS)  Acquisition 
Programs, "  requires  program  managers  (PMs)  to  tailor  a 
program  WBS  for  each  program  using  the  guidance  in  Military- 
Handbook-881  (DoD,  January  98).  MIL-HDBK-881 ,  "DoD  Handbook 
-  Work  Breakdown  Structure, "  presents  guidelines  for 
preparing,  understanding,  and  presenting  a  WBS.  The  purpose 
of  this  thesis  research  is  to  analyze  how  MIL-HDBK-881  can 
facilitate  or  impede  acquisition  reform  initiatives. 
Additionally,  this  research  will  consider  acquisition  reform 
initiatives  that  may  be  affected  by  the  WBS,  the  uses  of  the 
WBS,  how  to  develop  a  WBS,  and  an  alternative  method  to 
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structure  the  WBS  to  more  effectively  facilitate  or 
implement  acquisition  reform  initiatives. 

B.  BACKGROUND 

A  WBS  provides  a  consistent  and  visible  framework  for 
defense  materiel  items  and  contracts  within  a  program.  The 
WBS  provides  the  basis  for  communication  throughout  the 
acquisition  process.  It  is  the  common  link,  which  unifies 
the  planning,  scheduling,  cost  estimating,  budgeting, 
contracting,  configuration  management,  and  performance 
reporting  disciplines  (DoD,  January  1998) .  The  WBS  is  a 
product-oriented  family  tree  composed  of  hardware,  software, 
services,  data,  and  facilities.  The  family  tree  results 
from  systems  engineering  efforts  during  the  acquisition  of  a 
defense  materiel  item.  The  challenge  in  developing  a  WBS  is 
to  balance  the  program  definition  aspects  of  the  WBS  against 
its  data-generating  aspects. 

MIL-HDBK-881,  dated  2  January  1998,  is  a  conversion  of 
Military-Standard-881  {MIL-STD-881) ,  "Work  Breakdown 
Structures  for  Defense  Materiel  Items,"  with  no  substantive 
changes  in  WBS  definition  (DoD,  January  1998) .  During  the 
past  decade,  there  have  been  several  acquisition  reform 
initiatives  to  streamline  the  DoD  acquisition  management 
process .  Some  of  these  acquisition  reform  initiatives  are 
implemented  through  or  affected  by  the  WBS,  which  further 
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increases  the  challenge  to  balance  the  program  definition 
aspects  of  the  WBS.  As  a  DoD  civilian  with  fifteen  years  of 
DoD  acquisition  experience  in  US  Army  Program  Management  and 
Research,  Development,  and  Engineering  offices,  the 
researcher  has  developed  poorly-written  WBSs  and  as  a  result 
suffered  the  consequences  of  attempting  to  manage  with 
meaningless  data.  This  first-hand  experience  of  attempting 
to  balance  the  program  definition  aspects  of  the  WBS  with 
its  data-generating  aspects,  in  addition  to  acquisition 
reform  initiatives,  prompted  further  exploration. 

Many  of  the  assertions  and  conclusions  in  this  thesis 
are  based  on  experiences  and  discussions  with  Government  and 
contractor  personnel  during  my  career.  Mr.  Lawrence  Nee  and 
Mr.  Richard  Ess  of  the  US  Army  Project  Manager  for  Mines, 
Countermine,  and  Demolitions  have  provided  me  with 
invaluable  insight  to  managing  programs  from  a  DoD 
perspective.  Mr.  Jim  Bob  Bryant  and  Mr.  Kent  Jacobson  of 
then  Tracer  Aerospace  have  provided  me  with  invaluable 
insight  to  managing  programs  from  a  contractor's 
perspective.  I  have  attempted  to  implement  many  acquisition 
reform  initiatives  and  have  been  frustrated  by  not  being 
able  to  effectively  implement  them.  I  have  managed  and 
participated  in  an  Integrated  Product  and  Process 
Development  (IPPD)  environment  participating  in  Integrated 
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Product  Teams  (IPTs) .  I  have  participated  in  an  Alpha 
Contracting  process.  Many  of  the  assertions  and  conclusions 
in  this  thesis  are  a  result  of  discussions  during  IPT 
meetings  and  the  Alpha  Contracting  process . 

Part  of  the  assertions  and  conclusions  in  this  thesis 
are  a  result  of  the  various  acquisition  and  management 
courses  taken  while  attending  the  US  Naval  Postgraduate 
School  (NPS) .  I  will  be  graduating  soon  and  re-entering  the 
acquisition  workforce,  charged  with  managing  and  executing 
US  Army  acquisition  programs.  My  personal  objective  for 
this  thesis  was  to  integrate  the  lessons  learned  from  the 
various  NPS  courses  as  well  as  to  integrate  them  with  my 
acquisition  experience. 

C.  RESEARCH  QUESTIONS 

1.  Primary  Question 

To  what  extent  does  MIL-HDBK-881  facilitate  or  impede 
execution  of  acquisition  reform  initiatives? 

2.  Subsidiary  Questions 

a.  What  acquisition  reform  initiatives  does  the 
WBS  affect? 

b.  What  are  the  possible  uses  of  the  WBS? 

c.  What  does  the  project  manager  need  to 
consider  when  structuring  a  WBS? 
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d.  Is  there  an  alternative  method (s)  to 

structure  the  WBS  that  will  allow  better 
execution  or  implementation  of  acquisition 
reform  initiatives? 

D.  METHODOLOGY 

My  research  began  with  a  literature  review  of  DoD 
regulations,  directives,  handbooks,  web-sites,  magazine 
articles,  CD-ROM  systems,  and  other  library  infoimiation .  A 
thorough  review  of  MIL-HDBK-881  and  other  DoD  publications 
was  conducted.  The  WBSs  along  with  the  definitions 
presented  in  MIL-HDBK-881 's  Appendices  were  analyzed  to 
determine  if  WBSs  developed  in  accordance  with  guidance 
contained  in  MIL-HDBK-881  facilitated  or  impeded  acquisition 
reform  initiatives.  Based  on  these  findings,  an  alternative 
method  to  structure  the  program  WBS  was  developed.  Finally, 
the  alternative  program  WBS  was  analyzed  to  determine  if  the 
new  WBS  facilitated  or  impeded  acquisition  reform 
initiatives . 

E.  ORGANIZATION  OF  STUDY 

This  thesis  is  divided  into  five  chapters.  The  next 
chapter  provides  background  information  and  discussion  of 
acquisition  reform  initiatives  implemented  through  or 
affected  by  the  WBS.  Chapter  III  provides  background 
information  and  discussion  of  MIL-HDBK-881.  This  chapter 
discusses  the  possible  uses  the  WBS.  It  also  discusses  the 
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preparation  of  the  program  WBS  and  contract  WBS,  along  with 
challenges  a  project  manager  must  consider  during  the 
development  of  the  WBS.  This  includes  methods  to 
incorporate  or  effectively  implement  acquisition  reform 
initiatives . 

Chapter  IV  analyzes  a  program  WBS  developed  in 
accordance  with  the  guidance  contained  in  MIL-HDBK-881,  to 
determine  to  what  extent  MIL-HDBK-881  facilitates  or  impedes 
execution  of  acquisition  reform  initiatives .  Chapter  IV 
also  determines  an  alternative  method  to  structure  the 
program  WBS  that  will  allow  better  execution  or 
implementation  of  the  acquisition  reform  initiatives.  It 
then  analyzes  the  new  program  WBS  to  determine  to  what 
extent  MIL-HDBK-881  facilitates  or  impedes  execution  of 
acquisition  ref oirm  initiatives .  Chapter  V  concludes  the 
thesis  study  by  summarizing  the  findings,  answering  the 
research  questions,  and  presents  both  recommendations  for 
DoD  project  managers  and  areas  for  future  research. 

F.  BENEFITS  OF  THE  STUDY 

The  initial  benefit  of  this  study  is  that  DoD  project 
managers  and  students  of  DoD  acquisition  will  be  able  to 
better  understand  the  WBS  and  how  it  can  benefit  them  during 
cost,  schedule,  and  performance  risk  management.  The  second 
benefit  is  to  identify  methods  to  structure  the  WBS  that 
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will  allow  DoD  project  managers  to  more  effectively  execute 
acquisition  reform  initiatives  and  ultimately  save  the 
taxpayer  money.  Finally,  this  study  will  provide  beneficial 
comments  such  as  recommendations,  additions,  or  deletions 
and  any  pertinent  data,  which  may  be  of  use  in  improving 
MIL-HDBK-881. 
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II.  ACQUISITION  REFORM  INITIATIVES 


A.  INTRODUCTION 

Defense  spending  has  decreased  in  real  teinns  since 
1985,  causing  DoD  to  rethink  how  it  does  business. 
Acquisition  reform  is  a  basic  restructuring  of  the  way  the 
DoD  does  business.  The  goal  of  acquisition  reform  is  to  do 
the  job  better,  faster,  and  cheaper.  The  focus  has  been  to 
reduce  the  cost  of  the  acquisition  process  by  reengineering, 
consolidation,  increased  competition,  and  elimination  of 
activities  that  are  not  cost-effective  or  necessary,  i.e., 
value  added.  The  DoD  has  been  adopting  modern  business 
practices  to  achieve  world-class  standards  of  performance; 
streamlining  organizations  to  reduce  redundancy  and  maximize 
synergy;  applying  market  mechanisms  to  improve  quality, 
reduce  costs,  and  respond  to  customer  needs;  and  reducing 
excess  support  structures  to  free  resources  and  focus  on 
core  competencies  (Cohen,  1997).  We  must  provide  the 
warfighter  what  is  needed,  when  it  is  needed,  and  at  the 
best  available  price,  while  keeping  the  public  trust  in  the 
acquisition  process  by  exercising  good  judgment  and  adhering 
to  the  highest  standards  of  honesty  and  professionalism 
(Department  of  the  Army  (DA),  1999). 
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The  private  sector  has  been  changing  their  way  of  doing 

business  to  operate  more  efficiently  in  order  to  be 

competitive  in  a  global  marketplace.  Secretary  of  Defense 

William  S.  Cohen  wrote: 

For  too  long,  DoD  has  labored  under  support 
systems  and  business  practices  that  are  at 
least  a  generation  out  of  step  with  modern 
corporate  America.  DoD  support  systems  and 
practices  that  were  once  state-of-the-art  are 
now  antiquated  compared  with  the  systems  and 
practices  in  place  in  the  corporate  world. 

Other  systems  grew  up  in  their  own  defense- 
unique  culture  and  never  did  correspond  with 
the  best  business  practices  of  the  private 
sector.  This  cannot  and  will  not  continue. 

(Cohen,  1997)  . 

The  Defense  Reform  Initiative  (DRI)  addresses  the  DoD 
corporate  vision  of  igniting  a  revolution  in  business 
affairs  within  DoD  that  will  bring  to  the  Department, 
management  techniques  and  business  practices  that  have 
restored  American  corporations  to  leadership  in  the 
marketplace  (Cohen,  1997) .  The  DoD  has  been  eliminating 
barriers  that  will  allow  the  use  of  good  business  judgment. 
They  have  been  providing  tools  to  the  workforce,  to 
implement  smarter  ways  of  doing  business.  The  DoD  has  been 
adopting  many  of  these  successful  commercial  practices. 

There  is  not  a  consolidated  list  of  all  the  acquisition 
reform  initiatives.  The  DoD  Regulation  5000.1  and  DoD 
Regulation  5000. 2-R  have  been  modified  to  incorporate  many 
of  the  acquisition  reform  initiatives.  The  WBS  does  not 
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affect  all  of  the  acquisition  reform  initiatives.  This 
chapter  provides  background  information  and  discussion  of 
acquisition  reform  initiatives  implemented  through  or 
affected  by  the  WBS. 

B.  ACQUISITION  REFORM  INITIATIVES 

1.  Streamline  Acquisition/Adoption  of  Commercial 
Practices 

Vice  President  Al  Gore  stated,  "Government  should 
emulate  the  best  in  business,  learn  from  them,  and  adopt 
their  best  business  practices . "  He  also  stated, 

"Information  technology  is  changing  everything  from  the  way 
we  buy  equipment  to  the  way  we  fight"  (Kozaryn,  1998) .  The 
main  focus  of  streamlined  acquisition  and  adoption  of 
commercial  practices  has  been  to  reduce  cycle- time  (i.e., 
shortening  development  and  fielding  cycles  for  new 
technology)  and  change  from  oversight  to  insight.  This  will 
help  to  reduce  overhead  and  life-cycle  costs.  Reducing 
cycle-time  will  allow  advance  technology  to  be  fielded 
before  it  is  outdated.  We  can  no  longer  afford  to  develop 
systems  for  ten  to  fifteen  years  or  longer.  We  must  field 
technology  while  it  is  still  advanced  and  provides  our 
military  the  technological  advantage  over  our  enemies.  One 
commercial  practice  is  incremental  product  improvements  with 
short  cycle-times  and  continued  research  and  development 
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efforts  on  technological  advancements  which  can  be  inserted 
rapidly  when  proven  (Gansler,  1998)  .  The  use  of  Advanced 
Concept  Technology  Demonstrations  (ACTDs)  and  the  Army's 
Fast  Track  Acquisition  Program  are  other  techniques  to 
shorten  cycle-times  and  make  incremental  product 
improvements . 

With  oversight  management,  PMs  and  Milestone  Decision 
Authorities  (MDAs)  did  not  have  the  necessary  information  to 
understand  program  status  to  make  informed  decisions  in  a 
timely  manner.  This  wasted  valuable  resources,  i.e.,  time 
and  money,  by  not  making  timely  decisions.  DoD  cannot 
afford  to  rework  or  fix  mistakes  that  could  have  been 
eliminated  through  early  and  continuous  insight  to  resolve 
major  issues.  It  is  easier  to  change  paper  early  in  the 
acquisition  process  than  changing  hardware  later  in  the 
acquisition  process.  More  knowledge  shared  between  PMs,  the 
Users,  Government  personnel,  and  contractors  during  the 
acquisition  process  will  help  to  reduce  asstimptions  and 
decrease  the  amount  of  rework,  saving  DoD  money.  It  is 
markedly  cheaper  to  do  the  right  thing  the  first  time.  DoD 
Regulation  5000.1  encourages  PMs  to  continually  search  for 
innovative  practices  that  reduce  cycle-time,  reduce  cost, 
and  encourage  teamwork.  Teamwork  will  be  discussed  in  the 
next  section.  In  addition,  DoD  Regulation  5000.1  requires 
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continuous  focus  on  implementing  major  improvements 
necessary  to  streamline  the  acquisition  process,  reduce 
infrastructure,  and  enhance  customer  service  through  process 
reengineering  and  technological  breakthrough.  Techniques  to 
reduce  oversight  include  eliminating  all  but  the  most 
essential  data  requirements,  obtaining  access  to  the 
contractor's  own  management  data,  the  use  of  commercial-off- 
the-shelf  (COTS)  hardware  and  software,  and  the  use  of 
contractor  logistics  support. 

DoD  Regulation  5000.1  states,  "In  all  cases,  no  more 
than  two  levels  of  review  shall  exist  between  a  PM  and  the 
MDA. "  DoD  has  streamlined  the  acquisition  management 
structure  to  clearly  define  the  lines  of  responsibility, 
authority,  and  accountability.  This  has  minimized  reporting 
requirements  to  only  the  necessary  information  for  decision 
authorities  to  understand  program  status  and  make  informed 
decisions  in  a  timely  manner.  The  MDA  may  tailor  the 
acquisition  process,  including  program  dociamentation, 
acquisition  phases,  the  timing  and  scope  of  decision 
reviews,  and  decision  levels  (DoD,  March  1998) .  Tailored 
approaches  to  oversight  and  review  are  based  on  a  program's 
size,  risk,  and  complexity.  PMs  need  insight  to  actively 
manage  the  program's  cost,  schedule,  performance,  and  risks. 
They  can  do  longer  afford  to  be  risk-averse  and  must 
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actively  work  with  the  Users  and  contractors  to  conduct 
tradeoffs  between  cost,  schedule,  performance,  and  risk. 
Risk  management  encompasses  identification,  mitigation,  and 
continuous  tracking,  and  control  procedures  that  feed  back 
through  the  program  assessment  process  to  decision 
authorities  (DoD,  1999), 

On  24  November  1997,  the  US  Army  Aviation  and  Missile 
Command's  Acquisition  Center  for  Missile  Logistics 
Procurement  Directorate  received  the  Hammer  Award  for 
efforts  to  streamline  operations  and  cut  costs.  Vice 
President  Al  Gore  asserted  in  a  videotaped  statement,  "You 
cut  lead  time  by  45  percent,  which  translates  to  a  cost  cut 
to  taxpayers  of  500  million  dollars"  (Valine,  1998) .  DoD  is 
adopting  business  practices  to  streamline  business  and 
improve  efficiency.  This  is  especially  prevalent  with 
procurement  practices.  Adoption  of  commercial  practices 
enables  suppliers  to  efficiently  conduct  business  with  the 
Government  in  a  manner  similar  to  that  used  with  their 
private-sector  customers.  This  includes  the  use  of 
information  technology  and  electronic  commerce,  use  of 
common  processes,  use  of  simplified  acquisition  procedures 
and  credit  cards,  use  of  Single  Process  Initiatives  (SPI) 
(discussed  later) ,  simplified  acquisition  oversight 
procedures,  best-value  acquisition,  oral  presentations. 
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paperless  procurement,  multi-year  contracting,  and 
Government-industry  partnerships.  Past  performance  is  used 
as  a  prime  indicator  of  the  risk  of  non-performance. 

Allowing  the  contractor  to  be  responsible  for  configuration 
management  reduces  the  amount  of  oversight  and  allows  the 
contractor  to  more  quickly  modify  their  design.  Another 
practice  of  reducing  oversight  is  the  choice  of  contract 
type,  incentives,  or  warranties,  to  transfer  or  share  risk 
with  the  contractor. 

2.  Integrated  Product  and  Process  Development 
( I PPD) /Integrated  Product  Team  (IPT) 

In  May  of  1995,  Secretary  of  Defense  William  Perry 
directed  the  use  of  IPPD  concepts  and  the  use  of  IPTs  in  DoD 
acquisition  (Perry,  1995) .  The  use  of  IPPD  and  IPTs  were 
later  incorporated  into  DoD  Regulation  5000.1  and  DoD 
Regulation  5000. 2-R.  IPPD  is  a  management  technique  that 
simultaneously  integrates  all  acquisition  activities  through 
the  use  of  multidisciplinary  teams  (i.e.,  IPTs)  starting 
with  requirements  definition  through  production, 
fielding/deployment,  and  operational  support  to  optimize  the 
design,  manufacturing,  and  supportability  processes  (Perry, 
1995).  The  IPPD  approach  is  driven  by  the  customer's  need. 
The  use  of  IPPD  offers  the  potential  to  provide  better 
products  in  less  time  and  cost.  IPTs  enable  both  insight 
into  major  issues  early  and  making  the  right  decision  at  the 
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right  time.  The  IPT  concept  was  intended  to  replace  the 
sequential  acquisition  process  characterized  by  "throwing  it 
over  the  wall."  This  sequential  process  required  frequent 
reviews  and  normally  resulted  in  substantial  modifications 
or  rejection  of  the  product.  The  sequential  review  and 
approval  process  takes  considerably  longer  time  than  an  IPT 
approach  that  simultaneously  takes  advantage  of  all  members' 
expertise  and  produces  an  acceptable  product  the  first  time. 
(Office  of  the  Under  Secretary  of  Defense  for  Acquisition 
and  Technology  (USD(A&T)),  1995). 

IPTs  function  in  a  spirit  of  teamwork  with  participants 
empowered  and  authorized,  to  the  maximxim  extent  possible,  to 
make  commitments  for  the  organization  or  the  functional  area 
they  represent.  IPTs  are  composed  of  empowered 
representatives  (stakeholders)  from  all  of  the  functional 
areas  working  together  to  build  successful  and  balanced 
programs,  identifying  and  resolving  issues,  and  making  sound 
and  timely  decisions.  IPTs  enable  decision-makers  to  mhke 
the  right  decisions  at  the  right  time.  IPTs  are  composed  of 
personnel  from  program  management,  engineering, 
manufacturing,  test  and  evaluation,  logistics,  safety, 
financial  management,  contracting  including  contract 
administration,  contractors,  suppliers  and  the  most 
important,  the  customer  (Perry,  1995) . 


16 


IPTs  are  divided  into  three  layers,  an  Overarching  IPT 
(OIPT) ,  Working  IPTs  (WIPTs) ,  and  Program  IPTs.  Figure  2.1 
shows  the  IPT  structure.  The  OIPT  and  the  WIPTs,  facilitate 
building  more  successful  and  affordable  programs,  resolve 
problems,  and  gain  early  insight  for  program  insight.  DoD 
Regulation  5000. 2-R  requires  an  OIPT  and  at  least  one  WIPT. 
WIPTs  focus  on  a  particular  topic  such  as  cost /performance, 
test,  or  contracting.  An  Integrating  IPT  (IIPT) ,  which  is  a 
WIPT,  coordinates  WIPT  efforts  and  cover  all  topics  not 
otherwise  assigned  to  another  IPT.  The  IIPT  supports  the 
development  of  strategies  for  acquisition  and  contracts, 
cost  estimates,  evaluation  of  alternatives,  logistics 
management,  cost-performance  tradeoffs,  etc.  Participation 
in  IPTs  is  the  primary  way  for  any  organization  to 
participate  in  a  program.  Mandatory  guidance  relating  to 
these  types  of  IPTs  can  be  found  in  DoD  Regulation  5000. 2-R 
(Office  of  the  USD(A&T),  1995). 

Program  IPTs  are  established  to  manage  program 
execution.  They  perform  the  program  tasks.  The  integration 
of  contractors  with  the  Government  occurs  primarily  at  this 
level .  IPTs  are  usually  formed  around  the  key  products  and 
processes  associated  with  the  program.  The  WBS  is  based  on 
the  key  products  and  processes  in  a  product-oriented  tree 
structure.  The  program  IPTs  are  usually  structured  using 
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Figure  2.1.  BPT  Structure  (Extracted  from  Defense  Systems  Management  CoOege  (DSMC),  Systems 

Engineering  Fundamentals) 

the  WBS  and  designed  to  provide  the  maxim\im  vertical  and 
horizontal  communication  during  the  development  process  as 
shown  in  Figure  2.2  (DSMC,  October  1999). 

There  are  different  levels  of  Program  IPTs.  Level  one 
is  normally  a  program  management  IPT  and  a  system  IPT.  The 
next  level  is  either  product  or  process  IPTs .  Additional 
levels  may  exist  based  on  subsystems,  components,  or  sub¬ 
processes.  It  is  critical  that  these  IPTs  be  a  cohesive 
product /process  team  that  functions  efficiently  and 
effectively.  Each  IPT  has  a  mission  to  develop  and  deliver 
a  product  and  its  associated  processes.  At  the  program 
level,  IPTs  are  responsible  for  a  product  or  process, 
authority  over  the  resources  and  personnel,  an  agreed 
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Figure  2.2.  IPT  Structure  based  on  the  WBS  (Extracted  from  DSMC,  Systems  Engineering 

Fundamentals) 

schedule  for  delivery  of  the  defined  product,  an  agreed 
level  of  risk  to  deliver  the  defined  product,  and  an  agreed 
upon  set  of  measurable  metrics  (Office  of  the  USD(A&T), 
1998) .  Each  program  IPT  functions  as  a  small  program  with 
the  IPT  leader  serving  as  the  PM.  They  are  given  a  budget, 
schedule,  perfoinnance  requirements,  and  levels  of  risk.  An 
IPT  Charter  documents  the  above.  The  IPT  Charter  is 
essential  and  must  be  agreed  upon  by  management  and  team 
members  (Office  of  the  USD(A&T) ,  1998)  .  The  IPT  Charter 
should  clearly  describe  the  mission  and  goal  supplemented 
with  a  project  timeline;  team  members  and  their  authority 
and  accountability;  and  the  resources  they  control  and  team 
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deliverables.  If  a  program  deviation  or  a  breach  occurs  to 
the  agreed  to  thresholds,  they  are  raised  to  the  next 
higher-level  program  IPT  to  be  resolved. 

The  activities  relative  to  a  system's  acquisition 
change  and  evolve  over  its  life-cycle.  The  roles  of  various 
IPTs  and  IPT  members  evolve  as  well .  When  the  team  is 
dealing  with  an  area  that  requires  a  specific  expertise,  the 
role  of  the  member  with  that  expertise  will  predominate; 
however,  other  team  members'  input  should  be  integrated  into 
the  overall  life-cycle  design  of  the  product.  Some  teams 
may  assemble  to  address  a  specific  problem  and  then  become 
inactive  or  even  disband  after  accomplishing  their  tasks 
(Office  of  the  USD(A&T),  1998). 

The  DoD  Guide  to  IPPD  lists  the  following  ten 
interrelated  tenets  inherent  in  IPPD: 

1 .  Customer  Focus 

2 .  Concurrent  development  of  products  and  processes 

3 .  Early  an  continuous  life-cycle  planning 

4.  Maximize  flexibility  for  optimization  and  use  of 
contractor  approaches 

5.  Encourage  robust  design  and  improved  process 
capability 

6.  Event-driven  scheduling 

7 .  Multidisciplinary  teamwork 

8 .  Empowerment 

9 .  Seamless  Management  Tools 

10.  Proactive  identification  and  management  of  risk 
The  Rules  of  the  Road,  A  Guide  for  Leading  Successful 
Integrated  Product  Teams  lists  the  following  ground  rules 
for  implementing  IPTs: 
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•  Open  discussions  with  no  secrets . 

•  Qualified,  empowered  team  members. 

•  Consistent,  success-oriented,  proactive 
participation . 

•  Continuous,  "up-the-line"  communications. 

•  Reasoned  disagreement. 

•  Issues  raised  and  resolved  early. 

The  two  most  important  characteristics  of  IPTs  are 
cooperation  and  empowerment.  IPTs  must  have  full  and  open 
discussions  with  no  secrets,  working  toward  common  goals. 
All  members  must  be  able  to  speak  for  their  superiors  and 
not  be  overturned  later.  IPTs  with  Government  and 
contractor  members  must  have  a  relationship  of  partnership 
and  mutual  trust  versus  an  adversarial  relationship  (DoD, 
1995)  . 

A  successful  IPT  works  together  pulling  each  member's 
knowledge,  skills,  and  attitudes  through  the  spirit  of 
cooperation.  DoD  IPPD  HDBK  lists  the  following  principles 
that  must  exist  for  team  unity. 

•  All  team  members  must  be  stakeholders  in  the  mission 
of  the  group. 

•  All  team  members  must  be  empowered  and  capable  in 
their  functional  discipline. 

•  All  members  must  feel  free  to  make  suggestions. 

•  Members  must  trust  one  another,  especially  when 
sensitive  issues  surface. 

•  The  team  must  desire  consensus  and  remain  focused  on 
team  goals . 

•  All  members  must  actively  seek  win-win  solutions  to 
problems . 
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All  IPT  members  are  equal  and  have  a  vote  on  all  issues. 

The  goal  is  to  obtain  team  consensus  on  all  issues.  There 
can  be  disagreement  on  how  to  approach  a  particular  issue, 
but  that  disagreement  must  be  reasoned  disagreement  based  on 
an  alternative  plan  of  action  rather  than  unyielding 
opposition  (Perry,  1995) .  Team  members  must  be  willing  to 
live  with  the  solutions,  even  though  the  solution  is  not 
their  first  choice. 

3.  Cost  As  An  Independent  Variable  (CAIV) 

With  today's  lower  defense  budgets,  acquisition 
managers  are  faced  with  fiscal  constraints  in  an  environment 
of  interests  competing  for  limited  resources.  Cost  and 
schedule  pressures  along  with  changes  in  requirements, 
technology,  laws,  and  policies  require  acquisition  mangers 
to  constantly  tradeoff  between  these  competing  interests. 

We  cannot  afford  all  that  we  would  like  to  do,  so  we  must 
decide  what  is  not  going  to  be  accomplished.  PMs  conduct 
cost,  schedule,  and  performance  risk  management  on  a  daily 
basis.  Cost  as  an  independent  variable  (CAIV)  is  a 
management  technique  emphasizing  the  cost  or  unit  price  as  a 
constant.  Once  the  system  performance  and  objective  cost 
are  decided  (on  the  basis  of  cost -performance  tradeoffs), 
the  acquisition  process  makes  cost  more  of  a  constraint,  and 
less  of  a  variable,  while  obtaining  the  needed  military 
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capability  of  the  system  (Defense  Acquisition  Deskbook 
(DAD) ,  CAIV  Working  Group  Report,  1999) .  DoD  Regulation 
5000.1  states  that  cost  must  be  viewed  as  an  independent 
variable.  It  further  states  that  acquisition  mangers  shall 
establish  aggressive  but  realistic  cost  objectives  for  all 
programs  and  follow  through  by  trading  off  performance  and 
schedule,  beginning  early  in  the  program  (when  the  majority 
of  costs  are  determined) ,  to  achieve  a  balanced  set  of 
goals,  based  on  guidance  from  the  MDA.  DoD  Regulation 
5000. 2-R  states  that  cost  objectives  shall  also  be  set  to 
balance  mission  needs  with  projected  out-year  resources. 

PMs  must  actively  manage  risks  to  obtain  those  cost, 
schedule,  and  performance  objectives. 

CAIV  enables  PMs  to  refine  the  requirement,  consider 
cost  early,  and  make  tradeoffs  between  performance  and  cost 
to  obtain  an  affordable,  mission-effective  system  in  the 
end.  In,  the  past,  meeting  the  threat  dictated  an  emphasis 
on  performance  and  created  a  culture  in  which  cost  and 
schedule  were  adjusted  to  achieve  the  desired  outcome.  CAIV 
forces  IPTs  to  determine  cost  drivers  early  and  to  address 
them  promptly.  New  programs  that  employ  CAIV  from  the 
beginning  have  the  potential  to  generate  from  thirty  to 
fifty-percent  savings  in  total  life-cycle  costs,  and  ten  to 
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twenty-percent  savings  for  existing  programs  in  later 
acquisition  stages  (Hoeper  and  Kern,  1999) . 

CAIV  requires  the  user  to  be  an  active  and  strong 
participant  in  the  acquisition  process  since  CAIV  enables 
PMs  to  refine  the  requirements.  The  user  must  be  active  in 
the  IPTs  throughout  the  program,  during  the  establishment 
and  adjustment  of  program  goals,  particularly  in  the  cost- 
performance  tradeoff  process.  These  tradeoffs  have  the 
potential  to  empower  the  user  to  make  choices  that  provide 
the  best  performance-for-the-money  for  each  system,  thereby 
helping  to  ensure  maximum  benefit  from  all  systems  across 
the  force  within  the  resources  available.  CAIV  may  require 
larger  investments  early  in  the  program  in  order  to  realize 
long-term  savings  in  production  and  operation  and  support 
costs  (DAD,  CAIV  Working  Group  Report,  1999)  . 

CAIV  requires  the  user  to  state  system  requirements  in 
a  few  broad,  top-level  performance  terms.  These  performance 
requirements  are  stated  as  threshold  values,  the  minimum 
level  required  by  the  user,  and  objective  values, 
representing  a  relevant  improvement  over  the  threshold.  It 
also  requires  the  user  to  establish  a  few  Key  Performance 
Parameters  (KPP) .  The  KPPs  are  those  requirements  that  may 
not  be  traded  off  (Higgins,  1999) .  Failure  to  meet  a  KPP 
threshold  will  cause  the  MDA  to  reevaluate  the  concept  or 
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system  and  to  reassess  the  program.  Those  broad 
requirements  facilitate  CAIV  by  allowing  the  requirement  to 
be  satisfied  in  many  different  designs  or  approaches.  This 
allows  the  PM  and  contractor  to  focus  on  the  real 
warfighting  requirements  in  the  most  affordable  methods. 

CAIV  actually  increases  the  probability  of  fully  meeting  the 
requirements .  This  is  true  because  with  ample  trade  space 
available  to  the  designer,  intelligent  trades  can  be 
affected  quickly  and  efficiently  to  trade  lower-level 
requirements  to  meet  the  top-level  KPPs  and  meet  or  reduce 
costs  (Higgins,  1999) .  Lower  cost  designs  are  typically 
both  simpler  and  therefore  easier  to  manufacture,  and  more 
reliable  because  the  designers  find  themselves  forced  to 
invest  more  heavily  in  the  intellectual  challenges  of 
developing  creative  designs  to  meet  the  cost  criteria 
(Higgins,  1997)  . 

4.  Total  Ownership  Costs 

DoD  Regulation  5000.1  requires  acquisition  programs  be 
managed  to  optimize  total  system  performance  and  minimize 
the  cost  of  ownership.  What  are  "total  ownership  costs?" 
Total  ownership  costs  are  the  total  life-cycle  cost  (LCC) . 
LCC  is  the  total  cost  to  the  Government  of  a  program  over 
its  full  life  of  developing,  producing,  deploying, 
supporting,  and  disposing  of  a  system.  LCC  is  all  costs 
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that  would  not  occur  if  the  program  did  not  exist.  Total 
ownership  costs  are  all  the  costs  associated  with  a  system 
known  as  "cradle  to  grave."  The  Defense  Systems  Management 
College  (DSMC)  describes  a  successful  system  acquisition 
program  as  one  that  places  a  capable  and  supportable  system 
in  the  hands  of  a  user  when  and  where  it  is  needed,  and  does 
so  within  the  bounds  of  affordability  (DSMC,  1996)  .  DoD 
Regulation  5000. 2-R  defines  affordability  as  the  degree  to 
which  the  LCC  of  an  acquisition  program  is  in  consonance 
with  the  long-range  investment  and  force  structure  plans  of 
the  DoD  or  individual  DoD  Components.  Affordability 
procedures  establish  the  basis  for  fostering  greater  program 
stability  through  the  assessment  of  program  affordability 
and  the  determination  of  affordability  constraints.  LCC 
estimates  (LCCE)  form  the  basis  for  budget  requests  to 
Congress,  therefore  acquisition  managers  are  faced  with 
fiscal  constraints  that  are  based  on  the  LCCE. 

DoD  Regulation  5000. 2-R  states  that  the  best  time  to 
reduce  LCC  is  early  in  the  acquisition  process.  Cost 
reductions  are  accomplished  through  cost/performance 
tradeoff  analyses.  In  the  past,  acquisition  managers  would 
make  cost /performance  tradeoffs  early  in  the  acquisition 
process  based  on  their  current  budget  and  because 
performance  was  the  independent  variable  (performance  was 
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the  most  important  variable)  (Higgins,  1997) .  They  would 
not  consider  the  long-term  impacts  to  production, 
deployment,  operational,  support,  and  disposal  costs  of  a 
system.  They  were  focused  on  their  current  cost,  schedule, 
and  performance  issues,  which  were  mainly  based  on  their 
current  fiscal  constraints.  Additionally,  those  costs  were 
not  their  concern.  Their  performance  rating  was  not 
affected  by  future  costs  of  operating  and  sustaining  the 
weapon  system  that  they  were  developing.  They  could  "throw 
it  over  the  wall"  to  the  operational  and  sustainment 
commands,  who  had  to  accept  the  weapon  system  and  budget 
accordingly.  Defense  budgets  are  shrinking  or  remaining 
constant,  which  has  forced  DoD  to  require  acquisition 
managers  to  responsible  for  optimizing  a  weapon  system's 
total  ownership  costs  using  CAIV  and  IPTs . 

5 .  Performance  Specification 

A  1991  study  conducted  by  the  Center  for  Strategic 
International  Studies  (CSIS)  concluded  that  military 
specifications  resulted  in  higher  prices  for  DoD  purchases 
than  for  purchase  of  commercial  alternatives  that  could 
satisfy  the  same  requirements  (DSMC,  1997) .  In  the  past, 
the  use  of  performance  specifications  required  a  waiver.  On 
29  June  1994,  then  Secretary  of  Defense  William  Perry 
reversed  this  policy  by  directing  the  use  of  performance 


27 


specifications,  along  with  requiring  a  waiver  from  the  MDA 
for  the  use  of  military  specifications  and  military 
standards.  DoD  Regulation  5000.1  now  states  that  in 
solicitations  and  contracts,  standard  management  approaches 
or  manufacturing  processes  are  not  required.  It  further 
states  that  performance  specifications  will  be  used  in 
purchasing  new  systems,  major  modifications,  and  commercial 
and  nondevelopmental  items. 

DoD's  focus  is  now  on  performance,  rather  than  detailed 
designs,  to  better  concentrate  on  satisfying  the 
warfighters'  needs.  The  use  of  performance-based 
specifications  allows  maximum  trade  space  without 
compromising  the  KPPs  (DoD,  1998) .  The  performance 
specification  states  what  is  required,  not  how  to  accomplish 
it.  This  allows  IPTs  to  develop  innovative  approaches  to 
satisfy  the  warfighters'  needs  while  satisfying  CAIV  and 
total  ownership  costs  objectives.  The  use  of  performance 
specifications  allows  the  implementation  of  dual-use 
technologies  that  will  help  share  the  cost,  thereby  lowering 
the  cost  of  military  systems.  Dual-use  technologies  are 
technologies  that  can  be  used  for  both  military  and 
commercial  applications . 
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6.  Earned  Value  Management  System 

The  traditional  "cost /schedule  management"  has  been 
reengineered  as  "earned  value  management"  (EVM) ,  integrating 
cost,  schedule,  and  performance  aspects  of  acquisition 
programs.  The  cost/schedule  management  was  reengineered  to 
provide  insight  into  the  contractor's  efforts  and  processes 
and  to  have  acquisition  managers  take  ownership  of  the 
program  baseline.  The  purpose  of  an  earned  value  management 
system  (EVMS)  is  to  identify  cost  and  schedule  variances  in 
real  time,  to  allow  management  of  cost  and  schedule  risk. 
These  three  variables,  cost,  schedule,  and  performance,  are 
interrelated,  thus  planned  and  unplanned  changes  to  any  one 
variable  will  usually  affect  one  or  both  of  the  other 
variables.  The  EVMS  measures  work  accomplishment  versus 
technical  accomplishment.  Acquisition  managers,  both 
Government  and  contractor,  are  evaluated  according  to  cost, 
schedule,  and  performance.  They  need  to  understand  the 
relationship  between  these  variables  so  that  they  can  manage 
the  variables  to  reduce  the  potential  for  and  severity  of 
unplanned  changes  or  program  risk.  Effective  management 
control  systems  are  essential  for  managing  program  risk. 

The  management  control  systems  must  be  valid,  timely,  and 
auditable  to  properly  relate  cost,  schedule,  and  performance 
(DA,  1999). 
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Earned  value  (EV)  is  a  method  for  measuring  program 
performance.  It  compares  the  amount  of  work  that  was 
planned  known  as  the  Budgeted  Cost  of  Worked  Performed 
(BCWP) ,  with  what  was  actually  accomplished  known  as  Actual 
Cost  of  Worked  Performed  (ACWP) ,  to  determine  if  cost  and 
schedule  performance  is  as  planned.  A  program  baseline  is 
established  early  in  the  program  or  contract  and  variances 
to  this  baseline  are  reported.  Variance  analysis  is 
conducted,  which  provides  IPTs  with  the  information  they 
need  to  make  informed  management  decisions.  The  IPTs  need 
to  establish  cost  and  schedule  reporting  requirements  to 
identify  what  can  and  will  be  effectively  used  to  manage  the 
program.  Too  much  information  will  increase  the  cost  of 
maintaining  and  reporting  of  the  EVMS,  as  well  as  reducing 
the  effectiveness  of  the  EVMS. 

7.  Integrated  Management  Plan  (IMP)  and  Integrated 
Management  Schedule  (IMS) 

DoD  Regulation  5000.1  states  that  DoD  will  use  a 
rigorous,  event-oriented  management  process  that  emphasizes 
effective  acquisition  planning,  improved  and  continuous 
communications  with  users,  and  prudent  risk  management  by 
both  the  Government  and  industry.  This  means  that  the 
acquisition  process  is  based  on  significant  events  and  not 
arbitrary  calendar  dates.  The  Integrated  Management  Plan  or 
Integrated  Master  Plan  (IMP)  is  an  event-driven  plan  that 
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docxzments  the  significant  accomplishments  necessary  to 
complete  the  tasks  defined  in  the  statement  of  objectives 
(SOO)  or  the  statement  of  work  (SOW)  and  ties  these 
accomplishments  to  a  key  program  event.  Each  significant 
event  has  exit  criteria  to  facilitate  the  assessment  of 
successful  completion.  The  IMP  is  oriented  by  product  using 
the  WBS  numbering  system  and  contains  no  calendar 
information  (DA,  1999) . 

The  Integrated  Management  Schedule  (IMS)  or  Integrated 
Master  Schedule  (IMS)  is  a  detailed,  time-dependent,  task- 
oriented  schedule  of  the  effort  required,  to  accomplish  the 
program  and  its  relationship  to  the  events,  accomplishments, 
and  exit  criteria  identified  in  the  IMP.  The  IMS  is 
traceable  to  the  IMP  and  WBS,  and  contains  the  predecessors 
and  successors  tasks  and  their  dependencies .  The  IMP  and 
IMS  provide  the  Government  insight  into  how  the  contractor 
will  perform  work  (DA,  1999) . 

8 .  Alpha  Contracting 

Alpha  Contracting  is  an  innovative  use  of  IPTs  in  the 
pre-award  phase  of  sole-source,  negotiated  contracts.  Alpha 
Contracting  is  a  technique  that  uses  a  team  approach  to 
prepare,  evaluate,  and  award  proposals  in  substantially  less 
time  than  the  traditional  approach.  Alpha  Contracting  is  a 
concurrent  versus  a  serial  process  that  shortens  procurement 
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cycle-time  and  significantly  reduces  proposal  preparation 
costs.  The  goal  of  Alpha  Contracting  is  to  acquire  quality 
products  for  the  warfighter  in  an  expedited  and  efficient 
manner  at  a  fair  and  reasonable  price.  The  Alpha 
Contracting  IPTs  consist  of  the  user,  acquisition  managers, 
and  contracting  officers  from  both  the  Government  and 
contractor  to  include  principal  subcontractors,  the  Defense 
Contract  Audit  Agency,  the  Defense  Contract  Management 
Command  (DCMC) ,  and  various  support  organizations.  During 
Alpha  Contracting,  the  contract  and  cost  and  technical 
detail  are  jointly  developed  to  replace  the  solicitation  and 
proposal  with  a  "model  contract."  The  IPTs  adjusts  the 
model  contract  to  lower  cost  and  risk.  This  process  allows 
the  Government  to  have  greater  program,  insight  to  contract 
cost,  schedule,  performance,  and  risk.  Additionally,  this 
allows  the  contractor  to  fully  understand  what  is  required, 
eliminating  non-value  added  requirements  (DAD,  Army- 
Acquisition  Reform;  Tools  and  Techniques  Guidebook,  March 
1999; . 

9.  Single  Process  Initiative  (SPI) 

In  the  past,  DoD  contractors  have  been  inhibited  from 
making  major  changes  in  many  of  their  processes  because 
military  and  standard  specifications  dictated  how-to 
requirements.  The  Single  Process  Initiative  (SPI)  is  an 
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expansion  of  Secretary  of  Defense  Perry's  directive  to 
eliminate  military  and  standard  specifications  and  to  the 
use  performance  specifications.  The  goal  of  SPI  is  to 
eliminate  the  multiple  processes  imposed  by  various  existing 
DoD  contracts  into  a  single  common  commercial  process, 
thereby  saving  money,  obtaining  a  better  system  or  product, 
and  fostering  a  more  competitive  industry  (Kaminski,  1996) . 
SPI  provides  opportunities  for  contractors  to  reengineer  and 
standardize  processes  on  a  facility-wide  basis  when  it  makes 
good  business  sense.  This  not  only  includes  technical 
processes,  but  also  business  processes.  SPI  facilitates 
contractors  to  take  ownership  of  their  processes  and 
encourages  them  to  baseline  and  improve  their  processes  by 
applying  best  practices . 

C.  SUMMARY 

Acquisition  reform  is  about  saving  the  taxpayer  money, 
reinventing  Government,  strengthening  our  military,  and 
improving  the  economy.  At  the  core  of  acquisition  reform  is 
reducing  cycle-times  and  the  use  of  insight  versus 
oversight.  DoD,  the  Administration,  and  Congress  have  been 
removing  requirements  that  are  uniquely  imposed  on  defense 
contractors .  This  has  allowed  contractors  to  compete 
successfully  in  today's  global  marketplace,  ensure  DoD  has 
access  to  the  latest  technology,  and  assist  DoD  in  reducing 
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its  acquisition  costs.  The  way  DoD  procures  systems  is 
continuing  to  evolve  as  DoD  attempts  to  provide  the 
warfighter  the  best  product,  at  the  best  dollar  value,  in 
the  timeliest  manner.  There  have  been  many  acquisition 
reform  successes  and  failures,  but  DoD  is  searching  for  new 
ways  to  more  effectively  implement  and  accelerate 
acquisition  reform  initiatives.  How  one  prepares  the  WBS, 
may  be  one  of  those  techniques. 
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III.  OVERVIEW  OF  MIL-HDBK-881  "DEPARTMENT  OF  DEFENSE  (DOD) 
HANDBOOK  -  WORK  BREAKDOWN  STRUCTURE  (WBS)" 

A.  INTRODUCTION 

DoD  Regulation  5000. 2-R  requires  a  program  WBS  be 
established  that  provides  a  framework  for  program  and 
technical  planning,  cost  estimating,  resource  allocations, 
perfoirmance  measurements,  and  status  reporting,  using  the 
guidance  in  MIL-HDBK-881.  It  further  requires  that  the  WBS 
and  associated  WBS  dictionary  define  the  total  system  to  be 
developed  or  produced;  display  the  total  system  as  a 
product-oriented  family  tree  composed  of  hardware,  software, 
services,  data,  and  facilities;  and  relate  the  elements  of 
work  to  each  other  and  to  the  end  product.  It  also  requires 
that  MIL-HDBK-881  be  sited  in  solicitations  and  contracts 
"for  guidance  only"  in  extending  the  program  WBS  to  develop 
the  complete  contract  WBS  (DoD,  March  1998) .  This  chapter 
reviews  MIL-HDBK-881. 

B.  ISSUANCE 

MIL-STD-881  was  converted  to  MIL-HDBK-881  as  a  result 
of  the  performance  specification  acquisition  reform 
initiative.  There  were  no  substantive  changes  in  WBS 
definition  (DoD,  January  1998) .  MIL-HDBK-881  offers 
uniformity  in  definition  and  consistency  of  approach  for 
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developing  the  top  three  levels  of  the  WBS.  MIL-HDBK-881  is 
for  guidance  only  and  cannot  be  cited  as  requirement.  It 
was  issued  on  2  January  1998. 

C.  PURPOSE 

MIL-HDBK-881  provides  instructions  on  how  to  prepare, 
understand,  and  construct  a  program  WBS  in  the  context  of 
planning  and  monitoring  of  DoD  materiel  programs.  It 
provides  guidance  for  developing  and  implementing  a  contract 
WBS.  It  discusses  the  role  of  the  WBS  in  contract 
negotiation  and  award  and  in  post-contract  performance. 

It's  appendices  present  generic  definitions  of  WBSs  for 
several  DoD  system  categories .  The  primary  purpose  of  MIL- 
HDBK-881  is  to  provide  a  consistent  application  of  the  WBS 
across  DoD.  MIL-HDBK-881  can  be  applied  during  any 
acquisition  phase  (Concept  Exploration,  Program  Definition 
and  Risk  Reduction  (PDRR) ,  Engineering  and  Manufacturing 
Development  (EMD) ,  or  production) . 

D.  WBS  DEFINITION 

1 .  General 

The  WBS  is  a  tool  used  to  organize  acquisition 
development  activities  based  on  system  and  product 
decompositions.  The  WBS  is  a  tool  that  allows  PMs  to  break 
large  tasks  into  smaller,  understandable  tasks.  MIL-HDBK- 
881  states  the  WBS  will  be  developed  and  maintained  based  on 
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the  systems  engineering  efforts  throughout  its  life-cycle. 
MIL-HDBK-881  defines  the  WBS  as  follows: 

•  A  product-oriented  fcunily  tree  composed  of  hardware, 
software,  services,  data,  and  facilities.  The  family 
tree  results  from  systems  engineering  efforts  during 
the  acquisition  of  a  defense  materiel  item. 

•  A  WBS  displays  and  defines  the  product,  or  products,  to 
be  developed  and/or  produced.  It  relates  the  elements 
of  work  to  be  accomplished  to  each  other  and  to  the  end 
product . 

•  A  WBS  can  be  expressed  down  to  any  level  of  interest. 
However  the  top  three  levels  are  as  far  as  any  program 
or  contract  need  go  unless  the  items  identified  are 
high-cost  or  high-risk.  Then,  and  only  then,  is  it 
important  to  take  the  work  breakdown  structure  to  a 
lower  level  of  definition. 

MIL-HDBK-881  states  several  times  that  the  WBS  must  be 
product -oriented,  not  an  organization  structure.  It  should 
represent  identifiable  work  products  whether  they  be 
equipment,  data,  or  related  service  products. 

MIL-HDBK-881  appendices  present  definitions  of  WBSs  for 

seven  generic  DoD  system  categories,  which  can  be  used  as  a 

starting  point  to  construct  a  WBS  for  a  specified  program. 

The  WBS  for  each  of  the  seven  categories  is  included  in 

Appendix  A  through  G  of  this  document.  MIL-HDBK-881  defines 

the  following  system  categories : 

•  aircraft  system  —  applies  to  fixed  or  movable  wing, 
rotary  wing,  or  compound  wing  manned/unmanned  air 
vehicles  designed  for  powered  or  unpowered  (glider) 
guided  flight  (Appendix  A) 
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•  electronic /automated  software  system  --  applies  to 

electronic,  automated,  or  software  system  capability 
(Appendix  B) 

•  missile  system  —  applies  to  a  weapon  in  an 

operational  environment  which  produces  a  destructive 
effect  on  selected  targets  (Appendix  C) 

•  ordnance  system  —  applies  to  all  munitions  (nuclear, 
biological,  chemical,  psychological,  and 
pyrotechnic)  and  the  means  of  launching  or  firing 
them  (Appendix  D) 

•  ship  system  —  applies  to  naval  weapons,  or 
performing  other  naval  tasks  at  sea  (Appendix  E) 

•  space  system  —  applies  to  developing,  delivering, 

and  maintaining  mission  payloads  in  specific  orbit 
placement,  operation,  and  recovery  of  manned  and 
unmanned  space  systems  (Appendix  F) 

•  surface  vehicle  system  —  applies  to  navigation  over 

the  surface  (Appendix  G) 

2 .  Elements 

It  is  difficult  to  find  a  definition  of  an  element.  An 
element  of  the  WBS  should  represent  identifiable  work 
products  whether  they  be  equipment,  data,  or  related  service 
products.  MIL-HDBK-881  states  that  each  element  of  the  WBS 
provides  logical  summary  points  for  assessing  technical 
accomplishments  and  for  measuring  the  cost  and  schedule 
performance  accomplished  in  attaining  the  specified 
technical  objectives.  The  WBS  has  an  end  product  part  and 
an  enabling  product  part  (DSMC,  October  1999) .  The  end 
product  part  is  what  is  delivered  to  the  warfighter  and  is 
based  on  the  physical  structure  developed  from  the 
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requirements  or  the  product  development.  Figure  3.1 
presents  an  example  of  a  program  WBS  product  part.  The 
enabling  product  part  is  the  products  and  services 


Figure  3.1.  Program  WBS  -  The  Product  Part  (Extracted  from  DSMC,  Systems  Engineering 

Fundamentals) 


required  develop,  produce,  and  support  the  end  product. 
Figure  3.2  presents  an  example  of  a  complete  program  WBS  as 
defined  in  Appendix  A  for  an  aircraft  system  (DSMC,  October 
1999)  . 

MIL-HDBK-881  lists  these  common  elements  that  are 
pertinent  to  all  seven  DoD  system  categories.  They  are: 

•  integration,  assembly,  test,  and  checkout  efforts 

•  systems  engineering  and  program  management 

•  training 

•  data 

•  system  test  and  evaluation 

•  peculiar  support  equipment 

•  common  support  equipment 

•  operational  and  site  activation 

•  industrial  facilities 

•  initial  spares  and  repair  parts 
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Appendix  H  further  defines  these  common  elements. 
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Figure  3.2.  Complete  Program  WBS  for  an  Aircraft  System  (Extracted  from  DSMC,  Systems 

Engineering  Fundamentals) 


3.  Level  Identification 

The  WBS  is  divided  into  levels  of  hierarchy  as  can  be 
seen  in  Figure  3.1  and  Figure  3.2.  MIL-HDBK-881  defines  the 
top  three  levels  as: 

•  Level  1  is  the  entire  defense  materiel  item/  for 

example,  an  electronic  system.  An  "electronic  system" 
might  be  a  command  and  control  system,  a  radar  system, 
a  communications  system,  an  information  system,  a 
sensor  system,  a  navigation  or  guidance  system,  or  an 
electronic  warfare  system.  Level  1  is  usually  directly 
identified  as  a  program  or  a  sub-element  of  a  program. 

•  Level  2  elements  are  the  major  elements  of  the  defense 
materiel  item;  for  example,  a  fire  control  system  or  an 
automatic  flight  control  system.  These  prime  mission 
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products  include  all  hardware  and  software  elements, 
aggregations  of  system  level  services  (like  system  test 
and  evaluation,  or  systems  engineering  and  program 
management ) ,  and  data . 

•  Level  3  elements  are  elements  subordinate  to  level  2 
major  elements.  For  example,  a  radar  data  processor,  a 
signal  processor,  an  antenna,  a  type  of  service  (like 
development  test  and  evaluation,  contractor  technical 
support,  or  training  seirvices)  ,  or  a  type  of  data  (like 
technical  publications)  would  be  typical  level  3 
elements  for  an  electronic  system.  Lower  levels  follow 
the  same  process . 

E.  PRPGRAN  WBS  AMD  CONTRACT  MBS 

MIL-HDBK-881  describes  two  types  of  WBSs,  the  program 
WBS  and  the  contract  WBS.  The  PM  is  responsible  for 
preparing  and  maintaining  the  program  WBS.  It  describes  the 
program  WBS  as  the  structure  that  encompasses  an  entire 
program  and  provides  a  framework  for  specifying  the 
objectives  of  the  program.  The  program  WBS  consists  of  at 
least  the  three  top  levels  as  can  be  seen  in  Figure  3.2,  and 
is  used  to  develop  and  extend  the  contract  WBS.  The 
contract  WBS  includes  all  the  elements  of  the  program  WBS 
that  are  the  responsibility  of  the  contractor.  The  contract 
WBS  is  used  to  organize  and  identify  contractor  tasks. 

Figure  3.3  presents  only  the  product  part  of  the  contract 
WBS.  A  complete  contract  WBS  would  include  the  enabling 
products .  The  Fire  Control  element  is  at  level  3  of  the 
program  WBS,  but  it  is  at  level  1  of  the  contract  WBS  since 
that  is  the  product  the  Government  is  procuring.  The 
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contract  WBS  includes  the  applicable  program  WBS  elements 
extended  to  the  agreed  contract  reporting  level  and  any 
discretionary  extensions  to  lower  levels  based  on  high-cost 
or  high-risk.  The  contract  WBS  forms  the  structure  for  the 
contractor's  management  control  system. 


Figure  3.3.  Contract  WBS  (Extracted  from  DSMC,  Systems  Engineering  Fundamentals) 

Work  is  documented  as  resources  are  allocated  and 
expended  through  the  program  WBS  and  contract  WBS .  MIL- 
HDBK-881  states  that  technical,  schedule,  and  cost  data  are 
generated  for  reporting  purposes .  The  WBS  summarizes  the 
data  for  successive  levels  of  management  and  provides  the 
appropriate  information  on  the  projected,  actual,  and 
current  status  of  the  elements  for  which  they  are 
responsible.  This  allows  the  PM,  in  cooperation  with  the 
contractor,  to  monitor  program  status  so  that  they  can 
identify  and  implement  changes  necessary  to  assure  desired 
performance . 
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F.  DEVELOPING  A  NBS 

MIL-HDBK-881  breaks  this  into  two  chapters,  one  for  the 
program  WBS  and  one  for  the  contract  WBS.  The  generic  WBSs 
defined  in  Appendices  A  through  G  provide  the  basis  for  the 
program  or  contract  WBSs.  The  WBS  may  use  more  than  one  of 
the  categories  or  elements  defined  in  the  Appendices.  MIL- 
HDBK-881  allows  this  "as  long  as  the  integrity  of  the  level 
of  placement  is  maintained. " 

1.  Developing  the  Program  WBS 

MIL-HDBK-881  states  that  the  program  WBS  should  be 
developed  early  in  the  conceptual  stages  of  the  program.  It 
evolves  through  iterative  analysis  of  the  program  objective, 
functional  design  criteria,  program  scope,  technical 
performance  requirements,  proposed  methods  of  performance, 
and  other  technical  documentation.  The  program  WBS  elements 
are  selected  based  on  the  appropriate  product  parts  of  the 
system  being  developed  along  with  the  appropriate  enabling 
product  parts.  These  elements  can  consist  of  other  elements 
from  generic  categories.  The  systems  engineering  efforts 
aid  in  defining  the  description  of  the  system  and  its 
related  levels  throughout  the  life-cycle.  The  WBS  will 
become  more  defined  during  each  successive  acquisition  phase 
along  with  defining  lower  levels  of  the  WBS  reflecting  the 
way  business  is  planned  and  managed.  MIL-HDBK-881  states 
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that  the  levels  of  the  WBS  are  directly  linked  with  the 
detailed  configuration  of  the  system.  The  program  WBS  can 
be  both  the  program  and  contract  WBS  based  on  how  it  relates 
to  the  Government  activity.  For  example,  if  a  contract  were 
awarded  for  the  development  of  a  complete  system,  then  it 
would  be  both  a  program  and  contract  WBS . 

MIL-HDBK-881  states  that  for  each  WBS  element,  the 
detailed  technical  objectives  are  defined  and  specified  work 
tasks  are  assigned  along  with  the  resources,  materials,  and 
processes  required  to  attain  the  objectives.  The  linkage 
between  the  specification,  the  WBS,  the  SOW,  and  the  master 
and  detailed  schedules  provides  specific  insights  into  the 
relationship  between  cost,  schedule,  and  performance.  This 
relationship  allows  all  items  to  be  tracked  to  the  same  WBS 
element.  The  levels  of  the  program  WBS  should  be  related  to 
these  requirements  and  conform  to  its  product-oriented 
family  tree. 

2.  Developing  the  Contract  WBS 

The  PM  selects  WBS  elements  from  the  program  WBS  that 
apply  to  the  contract.  This  becomes  the  initial  contract 
WBS .  It  along  with  the  initial  contract  WBS  dictionary 
(discussed  later)  is  included  in  the  Request  for  Proposal 
(RFP) .  MIL-HDBK-881  States  that  the  RFP  should  instruct 
potential  contractors  to  extend  the  selected  contract  WBS 
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elements  to  define  the  complete  contract  scope.  MIL-HDBK- 
881  reiterates  that  the  contract  line  items,  configuration 
items,  contract  work  statement  tasks,  contract 
specifications,  and  contractor  responses  will  be  relatable 
to  the  WBS  to  enhance  its  effectiveness  in  satisfying  the 
objectives  of  the  particular  acquisition.  Combining  the 
program  WBS  with  the  contract  WBS(s)  will  form  a  complete 
WBS  of  the  program  for  use  throughout  the  acquisition  phase. 

The  contract  WBS  provides  the  framework  for  the 
management  control  system.  Contractors  submit  their 
extended  contract  WBS  with  their  proposal.  The  contractor's 
expanded  WBS  must  address  all  contract  WBS  elements  in  the 
RFP.  MIL-HDBK-881  states  that  their  proposed  contract  WBS 
should  be  based  on  the  WBS  in  the  RFP,  although  contractors 
may  suggest  changes  needed  to  meet  an  essential  requirement 
of  the  RFP  or  to  enhance  the  effectiveness  of  the  contract 
WBS  in  satisfying  program  objectives.  It  also  states  that 
contractors  are  expected  to  extend  the  contract  WBS  to  the 
appropriate  level  -  the  level  that  satisfies  the  critical 
visibility  requirements  and  does  not  overburden  the 
management  control  system.  MIL-HDBK-881  states  that 
contractors  should  include  lower  breakdown  levels  where  they 
identify  risk  associated  with  technical  issues  or  resources. 
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and  identify  control  plans  whether  or  not  the  items  are 

reported  back  to  the  Government. 

MIL-HDBK-881  states  that  WBS  revisions  may  result  due 

to  further  elements  selected  for  the  contract  will  become 

the  basis  for  contractor  extension  during  the  contracted 

effort  as  both  parties  become  more  knowledgeable  about  the 

effort.  MIL-HDBK-881  states  the  following  note: 

Normally,  once  work  is  underway  after 
contract  award,  changes  to  the  work  breakdown 
structure  should  not  be  made  unless  major 
rescoping  of  the  program  occurs . 

MIL-HDBK-881  states  that  the  WBS  should  not  influence 
or  in  any  way  affect  the  contractor's  program  organization. 
A  contractor  can  be  organized  in  any  way,  by  function, 
process,  or  IPT,  and  effectively  use  a  valid,  product- 
oriented  WBS .  This  is  because  at  some  level  in  an 
organization,  as  well  as  the  WBS,  a  cost  account  is  managed 
The  WBS  is  visible  regardless  of  the  contractor's 
organization. 

3.  WBS  Dictionary 

The  PM  develops  a  WBS  dictionary  while  developing  the 
program  WBS.  MIL-HDBK-881  states  the  requirement  for 
providing  the  WBS  dictionary  is  placed  in  the  Contract  Data 
Requirements  List  (CDRL) .  The  contractor  while  developing 
the  contract  WBS  expands  the  WBS  dictionary.  The  WBS 
dictionary  lists  and  defines  the  WBS  elements.  The  WBS 
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dictionary  defines  a  common  language  that  should  be  clearly 
understood  by  all  stakeholders.  It  should  eliminate  any 
possible  confusion.  MIL-HDBK-881  states  that  the  initial 
WBS  dictionary  should  be  based  on  the  generic  definitions  in 
the  handbook  and  made  program- specific  to  define  the 
products  being  acquired.  The  WBS  dictionary  describes  each 
WBS  element  and  the  resources  and  the  processes  required  to 
produce  it.  The  WBS  dictionary  should  be  routinely  revised 
throughout  the  program's  life  to  incorporate  changes  to  the 
program.  Figure  3.4  is  an  example  of  a  level  2  WBS  element 
dictionary  entry. 


Index  Item  No.  2 

WBS  Level  2 

CONTRACT  NUMBER 

F33657-72-C-0923 

WBS  Element 

A10100 

WBSTItle 

AirVehide 

Contract 

Line  Item: 

Date 

Revision  No. 

Revision  Auth 

Approved  Chg 

0001 , 0001 AA,  0001 AB,  0001 AC,  0001 AD 

0001 AE,  0001 AF,  0001 AG,  0001  AH 

Specification  No. 

689E078780028 

SpeclflcationTItle: 

Prime  Item  Development 

Spedficaiton  for  AGM  86A  AirVehide/ 
Airframe 

! 

ElementTask  Description 

Technics!  Content 

The  Air  Vehicle  element  task  description  refers  to  the  effort 
required  to  develop,  fabricate,  integrate  and  test  the 
airframe  segment,  portions  of  the  Navigatin/Guidance 
element,  and  Airborne  OevelopmentTest  Equipment  and 
Airborne  Operational  Test  Equipmentand  to  the  Integration 
assembly  and  check-out  of  these  complete  elements, 
togetherwith  the  Engine  Segment,  to  produce  the  complete 

Air  Vehicle.  The  lower-level  elements  included  and 
summarized  in  the  Air  Vehicle  element  are: 

Airframe  Segment  (A1 1100},  Navigation/Guidance 

Segment  (A321 00),  Airborne  Development  Test 

Equipment  (A61 100),  and  Airborne  Operational  Test 
Equipment  (A61200) 

Cost  Description 

MPC/PMC  Work  OrderyWork  Auth 

A10100  Seelowerlevel 

WBS  Elements 

Cost  Content^  System  Contractor 

The  cost  to  be  accumulated  against  this  element  includes 
a  summarization  of  all  costs  required  to  plan,  develop, 
fabricate,  assemble,  integrate  and  perform  development 
testing,  analysis  and  reporting  for  the  air  vehicle.  It  also 
includes  all  costs  assodated  with  the  required  efforts  in 
integrating,  assembling  and  checking  our  GFP  required  to 
create  this  element 

Applicable  SOW  Paragraph 

3.6.2 

Figure  3.4.  WBS  Dictionary  Level  2  Entry  (Extracted  from  the  DSMC,  Systems  Engineering 

Fundamentals) 
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4.  Avoiding  Pitfalls  in  Constructing  a  VJBS 

MIL-HDBK-881  states  that  a  sound  WBS  clearly  describes 
what  the  PM  wants  to  acquire.  It  has  a  logical  structure 
and  is  tailored  to  a  particular  materiel  item.  The  WBS  may 
tie  the  SOW,  contract  line  item  number  (CLIN)  structure,  and 
the  system  description  documents  together.  The  WBS 
addresses  the  products  required,  not  the  functions  or  costs 
associated  with  those  products.  MIL-HDBK-881  lists  the 
following  elements  that  are  to  be  excluded  from  the  WBS: 

•  Do  not  include  elements  which  are  not  products.  A 

signal  processor,  for  example,  is  clearly  a  product,  as 
are  mock-ups  and  Computer  Software  Configuration  Items 
(CSCIs) .  On  the  other  hand,  things  like  design 
engineering,  requirements  analysis,  test  engineering, 
aluminum  stock,  and  direct  costs,  are  not  products. 
Design  engineering,  test  engineering,  and  requirements 
analysis  are  all  engineering  functional  efforts; 
alxominum  is  a  material  resource;  and  direct  cost  is  an 
accounting  classification.  Thus  none  of  these  elements 
are  appropriate  WBS  elements . 

•  Prog-ram  phases  (e.g.,  design,  development,  production, 
and  types  of  funds,  or  research,  development,  test  and 
evaluation)  are  inappropriate  as  elements  in  a  WBS. 

•  Rework,  retesting  and  refurbishing  are  not  separate 
elements  in  a  WBS.  They  should  be  treated  as  part  of 
the  appropriate  WBS  element  affected. 

•  Non-recurring  and  recurring  classifications  are  not  WBS 
elements.  The  reporting  requirements  of  the  Contractor 
Cost  Data  Reporting  (CCDR)  will  segregate  each  element 
into  its  recurring  and  non-recurring  parts . 

•  Cost  saving  efforts  such  as  total  quality  management 
initiatives,  could  cost,  and  warranty  are  not  part  of 

the  WBS.  These  efforts  should  be  included  in  the  cost 
of  the  item  they  affect,  not  captured  separately. 


48 


•  Do  not  use  the  structure  of  the  program  office  or  the 
contractor's  organization  as  the  basis  of  a  f9BS. 

•  Do  not  treat  costs  for  meetings,  travel,  computer 
support,  etc.  as  separate  WBS  elements.  They  are  to  be 
included  with  the  WBS  elements  with  which  they  are 
associated. 

•  Use  actual  system  names  and  nomenclature.  Generic 
terms  are  inappropriate  in  a  WBS.  The  WBS  elements 
should  clearly  indicate  the  character  of  the  product  to 
avoid  semantic  confusion.  For  example,  if  the  Level  1 
system  is  Fire  Control,  then  the  Level  2  item  (prime 
mission  product)  is  Fire  Control  Radar. 

•  Treat  tooling  as  a  functional  cost,  not  a  WBS  element. 

Tooling  (e.g.,  special  test  equipment,  and  factory 
support  equipment  like  assembly  tools,  dies,  jigs, 
fixtures,  master  forms,  and  handling  equipment)  should 
be  included  in  the  cost  of  the  equipment  being 
produced.  If  the  tooling  cannot  be  assigned  to  an 
identified  subsystem  or  component,  it  should  be 
included  in  the  cost  of  integration,  assembly,  test, 
and  checkout. 

•  Include  software  costs  in  the  cost  of  the  equipment. 

For  example,  when  a  software  development  facility  is 
created  to  support  the  development  of  software,  the 
effort  associated  with  this  element  is  considered  part 
of  the  CSCI  it  supports  or,  if  more  than  one  CSCI  is 
involved,  the  software  effort  should  be  included  under 
integration,  assembly,  test,  and  checkout.  Software 
developed  to  reside  on  specific  equipment  must  be 
identified  as  a  subset  of  that  equipment. 


MIL-HDBK-881  does  not  identify  level  3  elements  for  the 
systems  engineering  and  program  management  WBS  elements.  It 
also  cautions  that  too  much  detail  may  limit  the  flexibility 
of  the  PM  and  the  contractor.  MIL-HDBK-881  states  that 
system  test  and  evaluation  always  separately  identifies 
those  tests  performed  in  the  development  test  and 
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evaluation,  i.e.,  development  test  and  evaluation,  and  those 
tests  performed  by  the  operational  user,  i.e.,  operational 
test  and  evaluation. 

MIL-HDBK-881  states  that  it  is  incorrect  to  summarize 
all  software  on  a  program  or  contract  in  a  WBS.  By 
separating  software  from  the  hardware  they  support, 
performance  measurement  and  management  control  over  each 
product  is  difficult  to  maintain.  The  true  cost  of  each 
product  is  not  readily  available  for  decisions  concerning 
that  product.  MIL-HDBK-881  states  that  rather  than 
separately  siimmarizing  software,  it  is  important  to  identify 
software  with  the  hardware  it  supports . 

5.  Integrated  Cost,  Schedule,  and  Technical 
Per£o2:iaance  Meuiagement 

The  prime  use  of  the  WBS  is  design  and  the  tracking  of 
work.  MIL-HDBK-881  states  that  planning  work  by  WBS 
elements  serves  as  the  basis  for  estimating  and  scheduling 
resource  requirements  known  as  work  packages .  A  work 
package  is  prepared  for  each  element  at  its  lowest  level  in 
the  WBS .  The  work  package  is  a  complete  description  for 
each  task.  It  includes  the  what,  how,  when,  by  whom,  and 
the  budget  for  each  task  (Forsberg,  Mooz,  and  Cotterman, 

1996)  .  Cost  accounts  are  created  when  the  WBS  element  is 
matrixed  against  those  organizations  in  the  company 
responsible  for  the  tasks  as  shown  in  Figure  3.5.  The 
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organization  structure  depicted  in  Figure  3.5  could  be  an 
IPT  organization  as  well.  The  WBS  divides  the  product  into 
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Figure  3.5.  WBS  Control  Matrix  (Extracted  from  DSMC,  Systems  Engineering  Fundamentals) 


smaller  increments  so  that  management  can  ensure  that  all 
required  products  are  identified  in  terms  of  cost,  schedule, 
and  performance  goals.  MIL-HDBK-881  states  that  virtually 
all  aspects  of  the  contractor's  management  control  system: 
technical  definition,  budgets,  estimates,  schedules,  work 
assignments,  accounting,  progress  assessment,  problem 
identification,  and  corrective  actions,  come  together  at  the 
cost  account  level.  Assigning  performance  budgets  to  work 


51 


segments  and  identifying  responsible  units,  produces  a  time- 
phased  plan  against  which  actual  performance  can  be 
measured.  An  IMP  and  IMS  can  now  be  created.  As  discussed 
in  Chapter  II,  the  IMP  is  the  specific  tool  used  to  track 
and  measure  successful  task  completion  and  is  event-based. 

G.  SUMMARY 

DoD  Regulation  5000.2  R  requires  a  program  WBS  be 
established  using  the  guidance  in  MIL-HDBK-881 .  MIL-STD-881 
was  converted  to  MIL-HDBK-881  as  a  result  of  the  performance 
specification  acquisition  reform  initiative.  MIL-HDBK-881 
provides  instructions  on  how  to  prepare,  understand,  and 
construct  both  a  program  WBS  and  a  contract  WBS.  MIL-HDBK- 
881  provides  seven  generic  DoD  system  categories.  The  WBS 
format  in  MIL-HDBK-881  is  to  be  used  as  a  starting  point  for 
constructing  and  tailoring  a  WBS.  The  WBS  is  a  tool  used  to 
organize  and  coordinate  work  to  be  completed  on  a  program. 
The  Government  PM  prepares  the  program  WBS  and  the  initial 
contract  WBS.  The  contractor  develops  lower  levels  of  the 
contract  WBS  based  on  the  work  required  by  the  contract. 

Work  packages  and  cost  accounts  are  established  along  with 
an  IMP  and  IMS,  which  become  the  baseline  against  which 
performance  is  measured. 
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IV.  ANALYSIS  OF  THE  WORK  BREAKDOWN  STRUCTURE  (WBS) 


A.  INTRODUCTION 

The  previous  chapters  presented  information  on 
acquisition  reform  initiatives  and  MIL-HDBK-881 ' s  guidance 
concerning  how  to  construct  a  WBS.  This  chapter  analyzes 
how  a  WBS  that  is  constructed  in  accordance  with  MIL-HDBK- 
881  facilitates  or  impedes  the  acquisition  reform 
initiatives  presented  in  Chapter  II.  Many  of  the  assertions 
and  conclusions  in  this  thesis  are  based  on  experiences  and 
discussions  with  Government  and  contractor  personnel  during 
my  career.  This  analysis  is  also  based  on  poorly-written 
WBSs  prepared  by  the  researcher  who  as  a  result,  suffered 
the  consequences  of  attempting  to  manage  with  meaningless 
data.  Before  conducting  this  analysis,  a  general  discussion 
concerning  the  various  perspectives  of  WBS  stakeholders,  the 
systems  engineering  process  (SEP) ,  and  considerations  when 
preparing  the  WBS  is  presented.  Then  based  on  this 
analysis,  an  alternative  WBS  is  developed  and  analyzed. 

B .  GENERAL 

The  major  stakeholders  in  constructing  the  WBS  are  the 
Government  PM,  Government  systems  engineer,  contractor  PM, 
and  the  contractor  systems  engineer.  How  a  WBS  is 
constructed  depends  on  each  of  their  perspectives.  As 
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stated  in  Chapter  I,  the  challenge  in  developing  a  WBS  is  to 
balance  the  program  definition  aspects  against  its  data- 
generating  aspects .  The  PMs  tend  to  focus  more  on  the  data- 
generating  aspects  of  the  WBS,  whereas  the  systems  engineers 
focus  more  on  the  program  definition  aspects  of  the  WBS. 

The  Government  and  contractor  PMs  require  the  WBS  be 
constructed  so  that  it  provides  insight  to  cost,  schedule, 
performance,  and  risk.  They  require  this  data  to 
effectively  manage  the  program.  The  Government  PM  is  trying 
to  ensure  that  the  Government  is  obtaining  the  best  value 
for  their  dollar  spent.  Additionally,  the  Government  PM  is 
attempting  to  ensure  the  program  will  be  completed  on  budget 
and  on  schedule  and  provide  the  desired  performance  required 
by  the  warfighter.  In  contrast,  the  contractor  PM  is 
attempting  to  ensure  they  have  insight  so  that  the  company 
obtains  a  profit,  as  well  as  ensuring  the  program  will  be 
completed  below  budget  and  ahead  of  schedule  and  provide  the 
desired  performance  required  by  the  warfighter.  The 
Government  and  contractor  systems  engineers  require  the  WBS 
be  constructed  so  that  they  can  clearly  define  the  products 
and  tasks  to  be  accomplished,  and  execute  the  program. 

Their  approaches  are  rarely  the  same  since  there  are  many 
possible  solutions  and  approaches  to  satisfy  a  requirement. 
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In  today's  acquisition  environment,  one  uses  an  IPT  to 
construct  a  WBS .  Additionally,  the  WBS  may  be  negotiated 
during  the  solicitation  process  to  ensure  that  both 
Government  and  contractor  perspectives  are  being  satisfied. 
Throughout  the  rest  of  this  analysis,  I  will  attempt  to 
balance  the  various  perspectives . 

C.  SYSTEMS  ENGINEERING  PROCESS  OVERVIEW 

The  systems  engineering  process  (SEP)  supports 
acquisition  decision-making.  It  is  the  basic  means  for 
planning  and  assessing  system  development.  Systems 
Engineering  (SE)  is  an  approach  that  encompasses  the  entire 
technical  effort  to  develop,  manufacture,  verify,  deploy, 
operate,  support,  dispose  of,  and  train  warfighters  on  the 
system  products  and  processes.  SE  is  the  balancing  of 
people,  products,  and  process  solutions  that  satisfy 
customer  (warfighter)  needs.  SE  attempts  to  answer  the 
question,  "How  do  you  create  a  product  that  a  customer 
needs,  will  be  able  to  use,  at  the  price  they  are  willing  to 
pay,  and  ensure  that  no  safety  hazards  exist?"  SE  involves 
the  discovery,  understanding,  focus,  invention,  action, 
feedback,  and  feed-forward  (sharing)  of  knowledge.  SE  poses 
questions  early  and  continuously  in  the  acquisition  process 
to  prevent  disasters,  increased  costs,  schedule  slippage, 
and  decreased  performance.  The  DSMC's  Systems  Engineering 


55 


Fundamentals  states  that  SE  is  an  interdisciplinary 
engineering  management  process  to  evolve  and  verify  an 
integrated,  life-cycle-balanced  set  of  system  solutions  that 
satisfy  customer  needs  (DSMC,  October  1999) . 

SE  defines  what  is  to  be  accomplished.  SE  does  not 
define  how  to  do  what  is  to  be  done.  Determining  how  to  do 
what  is  to  be  done  is  a  design  engineering  responsibility. 

SE  develops  a  description  of  system  parameters.  These 
system  parameters  are  documented  in  baseline  specifications. 
SE  is  responsible  for  conducting  tradeoffs  to  develop  the 
system  parameters .  The  SEP  progressively  decomposes  or 
allocates  the  system  requirements  to  the  lowest  level  of 
detail  (Forsberg,  Mooz,  and  Cotterman,  1996) . 

DoD  Regulation  50 00. 2 -R  requires  PMs  to  ensure  that  a  SEP  is 
used  to  translate  operational  needs  and/or  rec[uirements  into 
a  system  solution  that  includes  the  design,  manufacturing, 
test  and  evaluation,  and  support  processes  and  products. 

The  SEP  establishes  the  proper  balance  between  performance, 
risk,  cost,  and  schedule,  employing  a  top-down  iterative 
process  of  requirements  analysis,  functional  analysis  and 
allocation,  design  synthesis  and  verification,  and  system 
analysis  and  control,  as  shown  in  Figure  4.1.  Appendix  I  is 
extracted  from  Chapter  3  of  DSMC's  Systems  Engineering 
Fundamentals .  It  explains  the  SEP  depicted  by  Figure  4.1. 
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Figure  4.1.  The  Systems  Engineering  Process  (Extracted  from  DSMC,  Systems  Engineering 

Fundamentals) 


DoD  Regulation  5000. 2-R  recjuires  the  following  SE 
activities  depicted  in  Figure  4.1  to  be  performed: 

1.  Requirements  Analysis.  Throughout  the  acquisition 
process  the  program  office  shall  work  with  the  user  to 
establish  and  refine  operational  and  design 
requirements  that  result  in  the  proper  balance  between 
performance  and  cost  within  affordability  constraints. 
Requirements  analysis  shall  be  conducted  iteratively 
with  functional  analysis /allocation  to  develop  and 
refine  system  level  functional  and  performance 
requirements,  external  interfaces  and  provide 
traceability  among  user  requirements  and  design 
requirements . 

2.  Functional  Analysis /Allocation.  Functional 
analysis/allocation  shall  be  performed  iteratively  to 
define  successively  lower  level  functional  and 
performance  requirements,  including  functional 
interfaces  and  architecture.  Functional  and 
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performance  requirements  shall  be  traceable  to  higher 
level  requirements.  System  requirements  shall  be 
allocated  and  defined  in  sufficient  detail  to  provide 
design  and  verification  criteria  to  support  the 
integrated  system  design. 

3.  Design  Synthesis  and  Verification.  Design  synthesis 
and  verification  activities  shall  translate  functional 
and  performance  requirements  into  design  solutions  to 
include:  alternative  people,  product  and  process 
concepts  and  solutions,  and  internal  and  external 
interfaces.  These  design  solutions  shall  be  in 
sufficient  detail  to  verify  requirements  have  been  met. 
The  verification  of  the  design  shall  include  a  cost- 
effective  combination  of  design  analysis,  design 
modeling  and  simulation,  and  demonstration  and  testing. 
The  verification  process  shall  address  the  design 
tools,  products,  and  processes. 

4.  System  Analysis  and  Control.  System  analysis  and 
control  activities  shall  be  established  to  serve  as  a 
basis  for  evaluating  and  selecting  alternatives, 
measuring  progress,  and  documenting  design  decisions. 
This  shall  include: 

•  The  conduct  of  trade-off  studies  among  requirements 
(operational,  functional,  and  performance) ,  design 
alternatives  and  their  related  manufacturing, 
testing  and  support  processes,  program  schedule,  and 
life-cycle  cost  at  the  appropriate  level  of  detail 
to  support  decision-making  and  lead  to  a  proper 
balance  between  performance  and  cost. 

•  The  establishment  of  a  risk  management  process  to  be 
applied  throughout  the  design  process.  The  risk 
management  effort  shall  address  the  identification 
and  evaluation  of  potential  sources  of  technical 
risks  based  on  the  technology  being  used  and  its 
related  design,  manufacturing  capabilities, 
potential  industry  sources,  test  and  support 
processes,  risk  mitigation  efforts,  and  risk 
assessment  and  analysis.  Technology  transition 
planning  and  criteria  shall  be  established  as  part 
of  the  overall  risk  management  effort. 

•  A  configuration  management  process  to  control  the 
system  products,  processes,  and  related 
documentation.  The  configuration  management  effort 
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includes  identifying,  dociimenting,  and  verifying  the 
functional  and  physical  characteristics  of  an  item; 
recording  the  configuration  of  an  item;  and 
controlling  changes  to  an  item  and  its 
documentation.  It  shall  provide  a  complete  audit 
trail  of  decisions  and  design  modifications. 

•  An  integrated  data  management  system  to  capture  and 
control  the  technical  baseline  (configuration 
documentation,  technical  data,  and  technical 
manuals) ;  provide  data  correlation  and  traceability 
among  requirements,  designs,  decisions,  rationale, 
and  other  related .program  planning,  and  reporting, 
support  configuration  procedures,  and  serve  as  a 
ready  reference  for  the  systems  engineering  effort. 
PMs  shall  use  existing  information  systems  and  data 
formats  rather  than  DoD-unique  systems  and  formats, 
provided  they  can  readily  meet  the  program's 
information  requirements  and  do  not  pose 
compatibility  issues  with  operational  DoD 
information  systems  and  data. 

•  The  establishment  of  performance  metrics  to  provide 
measures  of  how  well  the  technical  development  and 
design  are  evolving  relative  to  what  was  planned  and 
relative  to  meeting  system  requirements  in  terms  of 
performance,  risk  mitigation,  producibility,  cost, 
and  schedule.  Performance  metrics  must  be  traceable 
to  performance  parameters  identified  by  the 
operational  user. 

•  The  establishment  of  interface  controls  to  ensure 
all  internal  and  external  interface  requirement 
changes  are  properly  recorded  and  communicated  to 
all  affected  configuration  items. 

•  A  structured  review  process  to  demonstrate  and 
confirm  completion  of  required  accomplishments  and 
their  exit  criteria  as  defined  in  program  planning. 
Reviews  necessary  to  demonstrate,  confirm,  and 
coordinate  progress  shall  be  incorporated  into 
overall  program  planning. 

In  today's  acquisition  environment,  IPTs  conduct  the 
SEP.  During  each  of  the  SEP  activities  (Requirements 
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Analysis,  Functional  Analysis/Allocation,  and  Synthesis), 
IPTs  will  conduct  System  Analysis  and  Control  activities  to 
obtain  knowledge  from  which  to  base  a  decision.  During 
System  Analysis  and  Control,  IPTs  attempt  to  solve  unknowns. 
This  is  an  iterative  process,  along  with  the  requirements 
loop,  design  loop,  and  verification  loop,  each  occurring 
several  times  during  an  acquisition  phase.  IPTs  attempt  to 
reduce  this  process  cycle-time  each  time  it  is  repeated.  No 
decisions  are  made  during  System  Analysis  and  Control 
activities.  IPTs  make  decisions  only  during  Requirements 
Analysis,  Functional  Analysis /Allocation,  and  Synthesis 
activities . 

During  System  Analysis  and  Control,  IPTs  use  modeling, 
simulation,  experimentation,  and  tests  to  obtain  the 
necessary  knowledge  to  make  a  decision.  Depending  on  the 
acquisition  phase,  thirty-percent,  fifty-percent,  seventy- 
percent,  ninety-percent,  or  full-scale  systems  will  be  used. 
Also,  these  systems  may  be  referred  to  as  prototype, 
preliminary,  detailed,  low-rate  production,  or  production 
systems.  Sub-scale  models /systems  usually  cost  less, 
require  less  time  to  fabricate,  and  have  lower  risk.  To 
reduce  risk  from  test  to  test,  developers  attempt  to  modify 
as  few  components  as  possible.  This  process  allows  them  to 
quickly  determine  the  cause  of  a  failure,  if  it  occurs. 
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This  process  also  allows  for  reduction  of  the  design, 
fabricate,  test,  analyze,  and  fix  cycle-time. 

The  SEP  depicted  in  Figure  4.1  is  conducted  throughout 
the  DoD  acquisition  phases  as  shown  in  Figure  4.2.  The  SEP 
produces  configuration  baselines  as  depicted  in  Figure  4.2. 
The  functional  baseline  is  the  initial  configuration 
baseline,  which  becomes  the  System  Specification.  As 
alternative  solutions  are  developed  and  more  knowledge  is 
gained  during  SEP  activities,  the  functional  requirements 
are  allocated  down  forming  the  allocated  baselines,  which 
become  the  Preliminary  Design  Specifications.  Again  as 
alternative  solutions  are  demonstrated  and  more  knowledge  is 
gained  during  later  SEP  activities,  the  allocated  baselines 
become  product  baselines,  which  become  detailed  item, 
process,  and  material  specifications  (DSMC,  October  1999) . 

At  the  end  on  each  SEP  cycle,  a  technical  review  is 
conducted  to  ensure  the'  phase  objectives  have  been  achieved. 
DoD  is  attempting  to  reduce  this  SEP  cycle-time  to  reduce 
costs  and  field  equipment  rapidly.  These  technical  reviews 
are:  Alternative  Systems  Review  (ASR) ,  Systems  Requirements 
Review  (SRR) ,  System  Functional  Review  (SFR) ,  Preliminary 
Design  Review  (PDR) ,  Critical  Design  Review  (CDR) , 

Functional  Configuration  Audit  (FCA) /System  Verification 
Review  (SVR) ,  Physical  Configuration  Audit  (PCA) ,  Test 
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Figure  4.2.  Systems  Engineering  and  the  Acquisition  Life-cycle  (Extracted  from  DSMC  Systems 

Engineering  Fundamentals) 
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Readiness  Review  (TRR) ,  and  Production  Readiness  Review 
(PRR) .  These  technical  reviews  are  depicted  in  Figure  4.2 
(DSMC,  October  1999) .  These  technical  reviews  should  be 
event-driven,  not  calendar-driven.  Normally,  a  test, 
examination,  or  demonstration  is  conducted  during  the 
verification  loop.  This  event  signals  that  adequate 
knowledge  is  known,  the  solution  satisfies  or  has  the 
potential  to  satisfy  the  requirements  (depending  on  the 
acquisition  phase) ,  and  that  the  program  is  ready  to  proceed 
through  the  next  phase  and  repeat  the  SEP. 

SE  is  about  doing  the  right  thing  right  the  first  time 
(Forsberg,  Moot,  and  Cotterman,  1996) .  IPTs  are  essential 
during  the  SEP  to  accomplish  this.  For  example,  changing 
paper  early  in  the  acquisition  process  is  easier  than 
changing  hardware  later  in  the  acquisition  process. 
Similarly,  modifying  a  sub-scale  system  is  easier  than 
changing  a  full-scale  system.  The  DSMC's  Systems 
Engineering  Fundamentals  states  that  the  SEP  management  is  a 
critical  support  process  for  DoD  acquisition.  If  the  SEP 
management  is  successful,  then  the  program  will  likely  be 
successful.  If  the  SEP  management  effort  fails,  then  the 
program  acquisition  effort  will  also  fail. 
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D.  CONSIDERATIONS  WHEN  STRUCTURING  A  WBS 

The  WBS  provides  a  consistent  and  visible  framework  for 
defense  materiel  items,  as  well  as  the  basis  for 
communication  throughout  the  acquisition  process.  The  WBS 
unifies  the  planning,  scheduling,  cost  estimating, 
budgeting,  contracting,  configuration  management,  and 
performance  reporting  disciplines.  The  WBS  will  take  a 
large,  complex,  unmanageable  program  and  break  it  into 
small,  easily-understandable  and  manageable  modules.  These 
smaller  modules  are  then  linked  to  define  a  complete 
program . 

DoD  acquisition  officials  and  PMs  want  to  have 
successful  programs.  They  require  tools  that  will  allow 
them  to  provide  the  warfighter  with  an  affordable, 
supportable,  and  operationally-ef fective  and  suitable  system 
when  it  is  needed.  They  want  to  know  what  they  are  doing, 
how  are  they  going  to  do  it,  and  when  they  are  planning  to 
do  it.  They  want  to  ensure  proper  planning  of  all  required 
tasks  to  successfully  meet  the  objectives  of  the  acquisition 
phase.  They  want  to  know  that  best  practices  are  being 
logically  employed  to  make  their  program  successful. 
Additionally,  they  want  to  know  what  are  the  high-risk  and 
high-cost  areas  that  will  require  their  attention.  The  WBS 
is  the  framework  to  allow  PMs  to  quickly  determine  what  they 
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are  doing,  how  are  they  going  to  do  it,  and  when  they  are 
planning  to  do  it. 

The  WBS  is  used  to  develop  schedules  and  cost 
estimates.  When  cost  and  schedule  estimates  are  developed 
early  in  the  life  a  program,  there  is  uncertainty  or  risk, 
usually  high-risk,  associated  with  the  estimates.  One  tends 
to  lose  sight  that  the  cost  and  schedule  estimates  are  the 
IPTs  best  point  estimate  chosen  from  a  range  of  possible 
outcomes.  IPTs  are  used  to  attempt  to  quantify  the  degree 
of  uncertainty.  A  Monte  Carlo  Simulation  tool  is  also 
useful  when  attempting  to  quantify  and  add  structure  to  cost 
estimating.  A  Monte  Carlo  Simulation  is  a  system  that  uses 
random  numbers  to  measure  the  effects  of  uncertainty  in  a 
spreadsheet  model  (Decisioneering,  Inc.,  1996).  With  a 
Monte  Carlo  Simulation  tool  like  Crystal  Ball,  an  IPT  can 
describe  a  range  of  possible  values  for  each  uncertainty. 

The  simulation  produces  a  forecasted  range  of  all  possible 
outcomes  along  with  the  likelihood  of  achieving  each 
outcome.  This  type  of  model  moves  beyond  what-if  analysis 
by  providing  a  statistical  picture  of  the  range  of 
possibilities  inherent  in  the  assxomptions  (Decisioneering, 
Inc.,  1996) .  Any  IPT  member  can  view  the  assumptions  for 
each  spreadsheet  entry.  These  assumptions  can  be  modified 
by  the  IPT  as  they  progress  through  the  acquisition  phase. 
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As  more  knowledge  is  gained,  the  IPT  can  refine  their 
assiamptions .  This  should  be  accomplished  before  each 
technical  review  depicted  in  Figure  4.2.  The  use  of  a  Monte 
Carlo  Simulation  tool  should  result  in  more  accurate  and 
realistic  estimates,  along  with  a  method  to  quantify  and  add 
structure  to  risk  management. 

E.  BASELINE  NBS 

To  conduct  this  analysis  to  determine  the  effectiveness 
of  a  WBS  constructed  in  accordance  with  MIL-HDBK-881  in 
implementing  acquisition  reform  initiatives,  a  baseline  WBS 
is  required.  In  Chapter  III,  I  have  used  a  WBS  for  an 
aircraft  system  presented  in  MIL-HDBK-881 's  Appendix  A. 

This  analysis  will  continue  to  use  the  aircraft  WBS  shown  in 
Figure  4.3  as  the  baseline  WBS. 

F.  ANALYSIS  OF  BASELINE  WBS  EFFECTIVENESS  IN  IMPLEMENTING 

ACQUISITION  REFORM  INITIATIVES 

1.  Streeunline  Acquisition/ Adopt  ion  of  Ccnnmercial 
Practices 

DoD  Regulation  5000. 2-R  requires  PMs  to  use  MIL-HDBK- 
881  to  construct  WBSs,  even  though  PMs  cannot  require 
contractors  to  use  MIL-HDBK-881.  MIL-HDBK-881  presents 
guidelines,  not  requirements,  for  preparing  WBSs.  MIL-HDBK- 
881  's  appendices  provide  a  WBS  for  seven  DoD  system 
categories.  The  baseline  aircraft  system  WBS  along  with 
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Figure  4.3.  Baseline  WBS  (Extracted  from  DSMC,  Systems  Engineering  Fundamentals) 


MIL-HDBK-881  allows  implementation  of  streamlined 
acquisition  and  adoption  of  commercial  practices.  It  is 
very  difficult  to  determine  the  effectiveness  of  the 
implementation.  Does  this  baseline  WBS  allow  insight  versus 
oversight  and  help  reduce  cycle-time? 

A  WBS  has  an  end  product  part  and  an  enabling  product 
part  (DSMC,  October  1999) .  The  end  product  part  of  the 
baseline  WBS  is  on  the  left  side  or  the  vertical  part  of  the 
WBS  in  Figure  4.3.  The  enabling  product  part  is  the 
horizontal  part  of  the  WBS  in  Figure  4.3.  So,  the  end 
product  part  has  one  level  2  element  and  several  level  3 
elements,  whereas  the  enabling  product  part  has  several 
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level  2  elements  and  a  few  level  3  elements .  Where  is  the 


greater  risk,  the  end  product  part  or  the  enabling  product 
part?  The  enabling  product  parts  are,  or  should  be, 
allocated  to  the  end  product  parts  during  the  SEP.  This 
assertion  is  based  on  experience  and  the  following  example. 
To  illustrate,  level  2  WBS  element.  Data,  is  divided  down 
into  Technical  Publications,  Engineering  Data,  Management 
Data,  Support  Data,  and  Data  Depository  elements.  Each  of 
the  end  product  parts  at  level  3  will  contain  each  of  these 
elements.  The  Airframe  will  have  Technical  Publications, 
Engineering  Data,  Management  Data,  Support  Data,  and  Data 
Depository,  as  well  as  Propulsion.  Technical  Publications 
(TPs)  are  not  a  difficult  task  and  could  be  considered  a 
work  package.  However,  if  the  TPs  are  not  available  when 
needed,  a  program  will  suffer.  So  a  PM  needs  to  ensure  that 
TPs  are  scheduled  and  then  empower  the  IPT  members  to  ensure 
the  task  is  completed.  If  the  allocation  of  the  enabling 
product  parts  to  the  end  product  parts  occurs,  then  there  is 
no  need  for  the  enabling  product  part  of  the  WBS  to  exist  at 
level  2.  They  would  exist  only  at  level  4,  or  lower,  for 
each  of  the  end  product  parts.  Thus  all  risk  should  be 
allocated  to  the  end  product  parts . 

Contractors  report  down  to  level  3  unless  otherwise 
directed  by  the  contract.  The  baseline  WBS  has  only  one 
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level  2  end  product  element  and  several  level  3  end  product 
elements.  The  PM  will  not  have  adequate  insight  into  these 
higher  risk  end  product  elements.  If  DoD's  objective  is  to 
increase  insight,  especially  into  those  high-risk  and  high- 
cost  elements,  then  the  end  product  elements  should  be  at 
level  2  of  the  WBS,  not  level  3.  This  will  require 
contractors  to  report  data  at  a  higher  level  and  in  more 
detail,  which  will  allow  PMs  to  have  greater  insight 
(visibility)  and  lead  to  early  identification  of  problem 
areas . 

MIL-HDBK-881  encourages  lower  level  reporting  where 
high  technical  risk  or  high-cost  exists.  This  is  contrary 
to  normal  business  practice.  If  a  PM  were  concerned  with  a 
specific  issue,  he  would  elevate  it  to  a  higher  level, 
requiring  it  to  be  reported  frequently  and  in  more  detail. 
Additionally,  one  tends  to  focus  on  levels  2  or  3  of  the 
contract  WBS  unless  there  is  a  variance  at  those  levels. 
This  assertion  again  is  based  on  my  experience  and 
discussions  with  Government  and  contractor  acquisition 
managers.  There  are  so  many  niombers,  that  you  attempt  to 
reduce  them  in  order  to  try  and  understand  them.  This 
higher  level  summarization  may  mask  lower  level  element 
variances.  For  example.  Figure  3.5  decomposes  the  baseline 
WBS  to  level  5 .  The  Receiver  Group  element  is  at  level  5 
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and  may  contain  software,  which  is  normally  high-risk  in  a 
program.  The  contractor  reports  data  to  level  5.  If  one  is 
reviewing  the  higher  WBS  levels  (2  and  3),  a  variance  may 
not  exist  because  the  level  3  elements.  Airframe  or 
Propulsion,  or  level  5  elements.  Antenna  or  Xmtr  Group,  may 
have  a  positive  variance.  This  positive  variance  may  offset 
the  negative  variance  of  the  Radar  or  Receiver  Group 
elements.  Therefore,  the  PM  would  not  have  early  insight  to 
the  software  problem.  Thus  the  PM  would  not  be  able  to 
execute  corrective  actions  to  prevent  negative  cost  or 
schedule  impacts.  At  the  higher  level  WBS,  the  PM  would 
have  early  insight  and  be  able  to  implement  corrective 
actions  to  mitigate  negative  program  impacts . 

The  next  part  of  the  question,  does  the  baseline  WBS 
help  to  reduce  cycle- time,  is  more  difficult  to  address. 
During  the  SEP,  tradeoffs  are  performed  by  IPTs.  The  end 
product  IPTs  will  conduct  tradeoffs  that  will  impact  the 
enabling  product  part  and  vice  versa.  With  the  enabling 
product  part  being  separate  from  the  end  product  part,  the 
potential  exists  for  no  communication  or  miscoramunication  to 
occur.  Additionally,  the  potential  for  the  tradeoff 
decision  to  negatively  impact  the  enabling  product  part  or 
vice  versa  also  exists.  If  either  of  the  above  occurs,  then 
the  cycle-time  is  not  shortened  because  the  tradeoff  process 
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will  have  to  be  repeated  or  the  program  will  experience  a 
higher  cost.  Both  results  are  unacceptable.  Thus  there  is 
a  potential  of  not  reducing  cycle-time  when  utilizing  the 
baseline  WBS. 

Based  upon  the  definitions  in  Appendix  H  of  MIL-HDBK- 
881  (Appendix  H  of  this  document) ,  how  IPTs  are  established 
and  function,  and  my  experience  of  working  in  an  IPPD 
environment,  I  assert  that  the  SE/Program  Management  element 
of  the  enabling  product  part  should  be  separated  into  two 
level  2  elements,  one  entitled  Program  Management  and  the 
other  entitled  Systems  Engineering  Integration.  Appendix  H 
contains  several  sub-element  descriptions  into  which  the  PM 
should  have  insight.  The  baseline  WBS  would  have  these  sub¬ 
elements  at  level  4  or  lower.  Again,  the  PM  would  not  have 
adequate  insight  into  the  contractor's  activities  to 
identify  problem  areas  early  enough  to  prevent  cost  and 
schedule  impacts.  Level  1  IPTs  are  normally  a  program 
management  IPT  and  a  system  IPT  (DSMC,  October  1999  and 
Office  of  the  USD(A&T),  1998).  Based  on  my  experience,  the 
PM  IPT  establishes  and  maintains  the  top-level  program  plan 
and  acts  as  program  integrator  of  the  lower  level  IPTs,  with 
the  authority  to  reallocate  cost  and  schedule  requirements 
between  IPTs.  Based  on  my  experience,  the  Systems 
Engineering  Integration  Product  Team  (SEIPT)  is  responsible 
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for  integration,  allocation,  and  verification  of  technical 
requirements.  Additionally,  based  on  my  experience  and  how 
IPTs  operate,  the  Program  Management  element  should  have  a 
sub-element  entitled  Business  Management.  Based  on  my 
experience,  PMs  are  extremely  busy  and  thus  cannot  attend 
each  lower-level  IPT  meeting  in  order  to  be  able  to  stay 
abreast  of  all  the  detailed  activities.  This  Business 
Management  sub-element  encompasses  the  planning  and 
management  of  all  business  areas  of  the  program  including: 
contracts,  subcontracts,  program  control,  finance,  capital 
equipment,  scheduling,  data  management.  Government  property, 
and  purchasing  and  pricing  (Tracer,  1998) .  A  member  from 
both  the  SEIPT  and  Business  Management  IPT  are  also  members 
of  the  lower-level  IPTs.  These  members  se2rve  as  the  "eyes 
and  ears"  of  the  entire  SEIPT  and  Business  Management  IPT. 
They  keep  the  various  plans  and  documents  updated  to  provide 
consistent  and  consolidated  documents  and  plans  to  the 
lower-level  IPTs,  the  PM  IPT,  and  the  Government.  This' 
allows  the  PM  to  have  a  clearer  picture  of  the  contractor's 
activities  and  facilitate  adoption  of  commercial  practices . 

As  stated  earlier,  the  Systems  Engineering  sub-element 
should  be  titled  Systems  Engineering  and  Integration. 

Systems  Engineering  is  mainly  focused  on  integrating  the 
subsystems  or  components.  MIL-HDBK-881  states  that  WBS 
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elements  should  clearly  indicate  the  character  of  the 
product  to  avoid  semantic  confusion,  therefore  the 
recommended  name  change  to  Systems  Engineering  Integration. 
This  name  better  reflects  and  emphasizes  the  tasks  to  be 
completed.  The  level  3  elements  under  this  level  2  element 
should  reflect  the  work  that  is  actually  being  planned  or 
accomplished  in  the  SEP.  Those  elements  would  be 
requirements  management,  technical  management,  support 
engineering  integration.  Integrated  Logistics  Support  (ILS) , 
reliability  and  maintainability.  Human  System  Integration 
(HSI) ,  manufacturing,  and  requirements  verification.  Based 
on  my  experience  and  lessons  learned  from  NPS  courses. 
Manufacturing  would  have  two  level  4  elements  entitled: 
producibility  program  and  quality  assurance.  ILS  will  be 
discussed  later.  These  elements  provide  a  clear  picture  of 
the  work  to  be  accomplished  for  the  system  being  developed. 
This  element  and  its  sub-elements  could  also  be  part  of  each 
end  product  part. 

2.  Integrated  Product  atnd  Process  Development 
(IPPD) /Integrated  Product  Team  (IPT) 

In  today's  acquisition  environment,  IPTs  are  used  to 
focus  on  products  and  processes.  IPTs  are  formed  using  the 
WBS  as  depicted  in  Figure  2.2  (DSMC,  October  1999).  The  end 
product  part  of  the  baseline  WBS  allows  implementation  of 
IPTs,  as  well  as  the  enabling  part  of  the  baseline  WBS.  How 
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effectively  are  the  IPTs  structured  by  the  baseline  WBS  and 
does  this  IPT  structure  allow  the  IPPD  process  to  be 
effectively  implemented?  Another  way  to  ask  this  question 
is,  does  this  baseline  WBS  allow  functional  stovepipes?  The 
enabling  product  part  does  allow  the  potential  for  test  and 
evaluation,  HIS,  and  ILS  stovepipes.  The  enabling  product 
part  consists  of  these  three  functional  areas.  If  the 
enabling  product  parts  are  not  allocated  to  the  end  product 
parts,  then  a  complete  multi-disciplinary  team  may  not 
exist.  Additionally,  if  an  IPT  is  not  allocated  all  life- 
cycle  requirements,  then  the  IPT  is  conducting  tradeoffs 
that  will  impact  other  IPTs.  As  discussed  above  in 
Paragraph  1,  the  potential  exists  for  repeating  the  tradeoff 
process . 

For  the  end  product  IPTs  to  effectively  function  as  a 
small  program  and  use  IPPD  techniques,  the  enabling  product 
part  needs  to  be  allocated  to  the  end  product  or  vice  versa. 
For  example,  the  enabling  product  part.  Common  Support 
Equipment,  is  broken  down  into  Test  and  Measurement 
Equipment  and  Support  and  Handling  Ecjuipment.  The  end 
product  part.  Propulsion,  may  require  both  Common  Support 
Equipment  elements.  During  the  SEP,  tradeoffs  are  conducted 
by  the  Propulsion  IPT  that  will  affect  the  Common  Support 
Equipment  IPT  or  vice  versa.  The  discrepancies  will  need  to 
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be  resolved  by  the  SEIPT,  which  may  require  the  tradeoff 
analysis  to  be  repeated  by  both  IPTs,  (Based  on  my 
experience,  if  an  allocated  requirement  is  breached  by  any 
lower  level  IPT,  it  is  raised  to  the  SEIPT  to  be  resolved.) 
Thus,  this  baseline  WBS  does  not  effectively  implement  IPPD 
and  IPTs. 

Before  continuing,  the  baseline  WBS  end  product  parts 
require  analysis.  Do  those  elements  breach  any  of  the 
guidelines  in  MIL-HDBK-881  and  are  they  actually  products? 

In  Chapter  III  under  "Avoiding  Pitfalls  in  Constructing  a 
WBS, "  MIL-HDBK-881  states,  "Include  software  costs  in  the 
cost  of  the  equipment."  The  Baseline  WBS  lists  two  elements 
entitled  Application  Software  and  System  Software  that  are 
in  direct  violation  of  MIL-HDBK-881.  Also,  many  of  these 
elements  are  requirements  that  should  be  allocated  to  true 
end  products.  Those  true  end  products  are  Airframe, 
Propulsion,  and  what  I  will  refer  to  as  the  Mission 
Equipment  Package  (MEP) .  This  was  determined  based  on 
conversations  with  US  Marine  Corps  Major  Eric  Chase  and  US 
Army  Captain  Jason  Galindo,  both  helicopter  pilots  attending 
NPS.  As  stated  earlier,  these  end  products  should  be  at 
level  2  of  the  WBS  since  they  are  high-cost  and  probably 
high-risk.  The  MEP  could  have  a  sub-product  entitled 
Cockpit.  If  the  Cockpit  were  a  high-risk  or  high-cost  sub- 
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component,  I  would  raise  it  to  level  2  for  the  reasons 
indicated  above. 

3.  Cost  As  An  Independent  VarieQ>le  (CAIV) 

The  baseline  WBS  allows  implementation  of  CAIV.  How 
effectively  does  the  baseline  WBS  implement  CAIV?  It 
depends  on  how  well  one  can  establish  a  cost  for  each 
element.  As  discussed  above,  the  potential  exists  for  the 
end  product  parts  to  affect  the  enabling  product  parts. 

Thus  cost  could  be  affected.  An  effective  manager  may  be 
able  to  eliminate  any  affects,  but  it  will  require 
continuous  monitoring.  Based  on  my  actual  experience  in 
implementing  CAIV,  it  was  next  to  impossible  to  accomplish 
utilizing  the  baseline  WBS.  If  a  test  failed  and  had  to  be 
repeated,  but  was  not  planned,  then  what  else  was  not  going 
to  be  accomplished  in  order  to  fund  this  additional  effort? 
What  risks  are  the  various  elements  absorbing?  How  does 
this  track  to  the  program  objectives  and  exit  criteria?  The 
costs  were  spread  across  several  elements  and  controlled  by 
several  IPTs .  The  coordination  required  to  resolve  this 
issue  was  very  complex,  requiring  several  man-hours  of 
effort,  which  eventually  resulted  in  the  WBS  and  EVMS  not 
being  used  to  manage  the  program. 

To  resolve  this  issue,  the  PM  IPT  looked  at  the  program 
objectives  for  the  PDRR  acquisition  phase  and  the  exit 
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criteria  established  by  the  MDA  to  enter  the  EMD  acquisition 
phase.  Those  objectives  were  then  allocated  to  the  SEIPT, 
along  with  the  questions,  "What  needs  to  be  done,  how  is  it 
going  to  be  done,  and  when  will  it  be  done?"  The  SEIPT  then 
allocated  these  objectives  to  the  appropriate  level  2 
Product  IPTs.  The  Product  IPTs,  along  with  active 
involvement  of  the  SEIPT,  determined  the  phases  or  smaller 
projects  required  to  meet  the  objectives.  The  IPTs  divided 
the  remaining  work  into  Flight  Test  2  through  Flight  Test  6. 
Each  Flight  Test  was  a  small  program.  The  PM  IPT  was  able 
to  track  all  resources  required  to  accomplish  the  objectives 
of  each  Flight  Test.  The  SEIPT  was  able  to  allocate  all 
requirements  to  each  Product  IPT  for  each  Flight  Test.  This 
process  assisted  in  being  better  able  to  identify  and 
monitor  the  high-risk  areas,  along  with  improved 
implementation  of  CAIV. 

4.  Total  Ownership  Costs 

DoD  Regulation  5000.1  requires  programs  be  managed  to 
optimize  total  system  performance  and  minimize  the  cost  of 
ownership.  Does  the  baseline  WBS  allow  this?  No,  because 
the  end  product  parts  are  not  allocated  to  the  enabling 
product  parts  and  most  of  the  end  product  parts  are  not  end 
products.  The  end  product  IPTs  are  performing  tradeoffs 
during  the  SEP,  but  they  are  not  responsible  for  total  cost 
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of  ownership.  The  end  product  IPTs  are  conducting  tradeoffs 
that  will  affect  test  and  evaluation,  training,  data, 
peculiar  and  common  support  equipment,  operational /site 
activation,  industrial  facilities,  and  initial  spare  and 
repair  parts,  all  of  which  are  not  allocated  to  them.  The 
outcome  of  these  tradeoffs  could  increase  or  decrease  unit 
cost  of  the  end  product,  but  decrease  or  increase  the  cost 
of  training. 

This  baseline  WBS  does  not  effectively  integrate 
logistics.  MIL-HDBK-881  states  that  the  acquisition 
logistics  element  should  be  accommodated  as  indicated  in  the 
upper  levels  of  the  WBS .  This  technique  creates  the 
potential  for  a  logistics  stovepipe  and  does  not  allow 
effective  tradeoffs.  ILS  needs  to  be  an  element  of  the 
SEIPT  and  further  allocated  to  each  end  product.  The 
logistics  engineer /manager  must  be  actively  involved  during 
all  acquisition  phases  in  both  the  SEIPT  and  each  end 
product  IPT  in  order  to  influence  the  design  to  reduce 
operating  and  maintaining  costs .  This  will  also  allow  the 
potential  for  design  influence  to  reduce  cost  of  training, 
data,  peculiar  and  common  support  equipment, 
operational/site  activation,  industrial  facilities,  and 
initial  spare  and  repair  parts.  As  with  the  discussion  on 
TPs,  these  elements  or  work  packages  are  not  difficult  to 
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accomplish.  The  concern  is,  if  they  are  not  accomplished  on 
time,  it  will  adversely  impact  the  program.  PMs  need  to 
ensure  the  sub-elements  or  work  packages  are  planned  and 
then  empower  the  IPTs  to  accomplish  them. 

Based  on  my  experience,  PMs  need  to  ensure  that  IPTs 
are  using  total  ownership  costs  or  life-cycle  cost  in  their 
tradeoffs.  There  are  many  different  cost  terms  and  it  is 
easy  to  become  confused  and  use  the  wrong  cost.  Other  cost 
terms  include:  development  cost,  flyaway  cost,  weapon  system 
cost,  procurement  cost,  program  acquisition  cost,  and 
operating  and  support  costs  (DSMC,  July  1999) .  A  contractor 
may  have  a  tendency  to  use  current  acquisition  costs  for 
that  phase  of  development,  because  they  control  that  cost 
data. 

5 .  Performance  Specification 

The  baseline  WBS  allows  the  use  of  performance 
specifications,  but  for  which  WBS  elements  do  you  prepare  a 
performance  specification?  For  example,  how  do  you  write  a 
performance  specification  for  Survivability?  A 
Survivability  performance  requirement  for  the  Airframe 
Performance  Specification  is  relatively  easier  to  prepare 
and  verify  than  to  prepare  and  verify  a  performance 
specification  for  survivability.  Based  on  my  experience, 
the  potential  exists  for  this  process  of  preparing 
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performance  specifications  to  be  very  complex,  along  with 
having  the  potential  for  a  requirement  to  not  being 
allocated,  or  of  being  allocated  to  the  wrong  end  product. 
The  enabling  product  parts  must  be  allocated  to  the  end 
product  parts  to  effectively  document  the  performance 
specifications  for  each  end  product  part.  Also,  the  end 
product  parts  should  be  products,  not  requirements. 

6.  Earned  Value  Memag^ent  System  (EVMS) 

The  baseline  WBS  allows  implementation  of  the  EVMS, 
although  it  does  not  allow  adequate  insight  into  the  high- 
risk  areas  of  the  end  product  parts.  The  EVMS  requires 
contractors  to  report  down  to  level  3  of  the  contract  WBS 
unless  an  element  has  high  technical  risk  or  high-cost.  In 
this  case,  the  contractor  reports  down  to  the  lower  levels. 
Also,  if  a  variance  exists,  then  the  contractor  must  report 
to  the  lowest  level  to  explain  the  variance  and  to  identify 
the  corrective  action.  As  discussed  earlier,  the  end 
product  parts  are  higher  risk  than  the  enabling  product 
parts  and  a  variance  may  not  exist  at  the  baseline  level  3 
elements  because  positive  variances  may  cancel  negative 
variances  at  level  4 .  The  probability  of  a  variance 
occurring  with  the  enabling  product  parts  is  very  low. 

Thus,  the  EVMS  is  not  allowing  adequate  insight  into 
potential  high-risk  areas . 
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The  WBS  is  the  framework  for  the  EVMS  to  allow  PMs  to 


quickly  determine  what  they  are  doing,  how  are  they  going  to 
do  it,  and  when  they  are  planning  to  do  it.  The  baseline 
WBS  does  not  effectively  provide  the  framework  to  allow  PMs 
to  quickly  determine  what  they  are  doing,  how  are  they  going 
to  do  it,  and  when  they  are  planning  to  do  it.  As  stated 
earlier,  the  WBS  should  reflect  the  key  products  and 
processes  that  are  of  high-risk  and  high-cost.  The  EVMS 
should  reflect  IPPD  and  SEP  activities.  Is  the  contractor 
or  the  IPTs  applying  the  SEP  and  best  practices  to  develop 
the  end  products?  It  will  be  difficult  to  assess  since  the 
low-cost,  low-risk,  high-cost,  and  high-risk  elements  are 
all  entangled.  The  EVMS  must  provide  PMs  with  the  right 
information  and  at  the  right  time.  The  EVMS  must  highlight 
potential  problem  areas  that  allow  the  PM  to  implement 
corrective  actions  to  prevent  negative  program  impacts. 

MIL-HDBK-881  does  not  allow  low-risk  elements  to  be 
placed  at  a  lower  WBS  level.  MIL-HDBK-881  cautions  that  the 
integrity  of  the  level  of  placement  be  maintained  and  not  to 
overburden  the  contractor's  management  control  system. 

Based  on  my  experience,  the  baseline  WBS  is  having  the 
contractor  report  EVMS  data  that  is  of  no  use  to  the 
contractor  or  the  Government. 
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7.  Integrated  Management  Plan  (IMP)  emd  Integrated 
Management  Schedule  (IMS) 

The  baseline  WBS  allows  implementation  of  the  IMP  and 
IMS.  The  baseline  WBS  allows  the  contractor  to  develop  an 
event-oriented  plan  that  can  be  translated  into  a  detailed, 
time -dependent,  task-oriented  schedule.  How  effectively 
does  the  baseline  WBS  allow  implementation?  The  WBS  is  the 
framework  to  allow  PMs  to  quickly  determine  what  they  are 
doing,  how  are  they  going  to  do  it,  and  when  they  are 
planning  to  do  it.  The  baseline  WBS  contains  level  2 
elements  that  are  low-cost  and  low-risk.  They  should  be 
allocated  to  the  end  products.  The  baseline  WBS  end 
products  are  not  all  end  products.  They  are  requirements 
that  should  be  allocated  to  the  high-cost  and  high-risk  end 
products.  The  baseline  WBS  does  not  effectively  provide  the 
framework  to  allow  PMs  to  quickly  determine  what  they  are 
doing,  how  are  they  going  to  do  it,  and  when  are  they 
planning  to  do  it.  An  effective  IMP  must  dociiment  the 
significant  accomplishments  to  be  completed  that  lead  to  a 
key  program  event.  This  is  difficult  to  accomplish  with  the 
Baseline  WBS  since  low-cost,  low-risk,  high-cost,  and  high- 
risk  elements  are  all  intertwined.  If  the  IMP  is  not 
effective,  then  the  IMS  will  most  likely  not  be  effective. 
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Therefore,  an  IMP  and  IMS  developed  from  the  baseline  WBS 
does  not  effectively  implement  an  IMP  and  IMS. 

8 .  Alpha  Contracting 

Alpha  Contracting  allows  the  baseline  WBS  to  be 
developed.  Alpha  Contracting  would  allow  the  Government  and 
contractor  to  address  the  concerns  raised  in  the  above 
paragraphs.  Based  on  my  experience,  this  may  result  in  the 
baseline  WBS  not  being  constructed  in  accordance  with  MIL- 
HDBK-881.  The  Government  and  contractor  would  jointly 
develop  the  baseline  WBS  based  on  their  joint  interpretation 
of  risks  and  costs. 

9.  Single  Process  Initiative  (SPI) 

The  SPI  may  not  allow  the  baseline  WBS  to  be  developed. 
If  a  contractor  has  an  approved  procedure  for  developing  a 
WBS  that  is  not  based  on  MIL-HDBK-881,  then  the  baseline  WBS 
would  not  be  developed.  Their  procedure  may  result  in  a 
better  or  a  worse  baseline  WBS.  The  WBS  may  need  to  be 
negotiated  during  the  solicitation  process  to  ensure  that 
the  Government  will  be  obtaining  useful  data  with  which  to 
manage  and  track  the  contractor's  progress. 

6.  DEVELOPMENT  OF  AN  ALTERNATIVE  WBS 

An  alternative  WBS  has  been  developed  by  the  researcher 
based  upon:  the  above  analysis,  the  information  presented  in 
this  thesis,  my  experience  especially  from  actively 
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participating  in  Alpha  Contracting  for  award  of  an  EMD 
program  and  the  conversion  of  the  PDRR  program,  and  a 
diagram  depicted  by  Blanchard  (1998)  in  his  book  entitled 
"Logistics  Engineering  and  Management."  The  diagram 
depicted  a  sample  WBS  which  divided  the  program  into  two 
projects  entitled  "Preliminary  System  Design  Phase"  and 
"Detailed  Design  and  Development  Phase."  These  are  phases 
of  an  EMD  program  going  through  the  SEP.  This  diagram 
divided  the  program  into  smaller,  more  manageable  phases  or 
projects,  versus  baseline  elements.  The  alternative  WBS  is 
based  on  a  program  in  the  EMD  acquisition  phase.  The  basic 
concept  used  to  develop  the  alternate  method  was  to  focus  on 
the  key  products  and  processes  that  need  to  be  accomplished 
to  allow  the  objectives  of  an  acquisition  phase  to  be 
successfully  completed.  Then  projects  were  identified  for 
each  key  product  and  process  that  needed  to  be  accomplished 
to  allow  the  objectives  of  the  product  or  process  to  be 
successfully  completed  for  an  EMD  program.  The  alternative 
WBS  is  shown  in  Table  4.1. 

Level  1  of  the  WBS  remained  unchanged.  Level  2  and 
level  3  of  the  WBS  have  changed  significantly.  End  product 
parts  and  enabling  product  parts  are  not  as  easily  visible 
with  this  alternate  WBS  design;  although,  the  titles  of  the 
elements  allows  one  to  quickly  distinguish  between  them. 

This  alternate  design  is  focused  on  major  end  products  and 
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Level  1 

Level  2 

Level  3 

Aircraft  System 

Systems  Engineering 
&  Integration 

Requirements  Management 

Technical  Management 

Support  Engineering  Integration 
Integrated  Logistics  Support 
Reliability  &  Maintainability 

Human  Systems  Integration 
Manufacturing 

Producibility  Program 

Quality  Assurance 

Requirements  Verification 

Program  Management 

Program  Management 

Business  Management 

Airframe 

Airframe  Preliminary  Design 

Airframe  Detailed  Design 

Airframe  Requirements  Verification 
Airframe  Manufacturing  Process 
Development 

Propulsion 

Propulsion  Preliminary  Design 
Propulsion  Detailed  Design 

Propulsion  Requirement  Verification 
Propulsion  Manufacturing  Process 
Development 

:  Mission  Equipment 
Package  (MEP) 

MEP  Preliminary  Design 

MEP  Detailed  Design 

MEP  Requirements  Verification 

MEP  Manufacturing  Process 

Development 

Cockpit 

Cockpit  Preliminary  Design 

Cockpit  Detailed  Design 

Cockpit  Requirements  Verification 
Cockpit  Manufacturing  Process 
Development 

Hardware  Production 

Airframe  Production 

Propulsion  Production 

MEP  Production 

Cockpit  Production 

Table  4.1.  Alternate  WBS  (Source:  Created  by  author) 


processes  that  are  key  to  the  success  of  an  EMD  program. 

Then  projects  were  identified  for  each  key  product  and 
process  that  need  to  be  accomplished  to  allow  the  objectives 
of  the  product  or  process  to  be  successfully  completed  for 
an  EMD  program.  One  might  use  a  title  of  Low  Rate  Initial 
Production  (LRIP)  Hardware  instead  of  Hardware  Production. 

An  alternate  WBS  designed  for  the  PDRR  acquisition  phase  may 
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not  have  Hardware  Production  as  an  element,  since  one  does 
not  normally  build  a  significant  amount  of  product ion- like 
systems  for  system-level  requirements  verification 
(testing) .  In  PDRR,  you  may  not  have  a  Component 
Preliminary  Design  and  Detailed  Design  element.  Instead, 
you  may  have  a  Component  Thirty-Percent  Mockup,  Seventy-  ' 
Percent  Mockup,  Ninety-Percent  Mockup,  and  Prototype  Design 
elements.  The  concept  is  to  divide  the  program  into  smaller 
programs  for  each  design  phase  or  product  that  is  being 
planned  during  the  acquisition  phase. 

Based  on  experience.  Air  Vehicle  is  not  an  element  in 
this  alternate  WBS.  An  Air  Vehicle  is  composed  of  an 
Airframe,  Propulsion,  and  MEP  which  includes  Cockpit.  The 
Air  Vehicle  requirements  are  allocated  to  those  elements  or 
products.  This  allocation  is  accomplished  within  the 
Systems  Engineering  and  Integration  level  2  element.  Thus, 
the  Systems  Engineering  and  Integration  element  is  the  Air 
Vehicle,  but  Systems  Engineering  and  Integration  more 
clearly  depicts  the  work  to  be  accomplished. 

The  level  3  elements  of  Systems  Engineering  and 
Integration  would  also  be  level  4  elements  for  each 
Component  level  3  elements.  For  example,  the  Airframe 
Preliminary  Design  would  contain  all  the  level  3  elements  of 
Systems  Engineering  and  Integration  except  the  Manufacturing 
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element  which  may  change  to  be  entitled  Fabrication,  Some 
of  the  level  3  elements  of  Systems  Engineering  and 
Integration  may  not  be  included  in  the  Component 
Manufacturing  Process  Development  or  their  titles  may  change 
to  better  indicate  the  work  to  be  accomplished. 

H.  ANALYSIS  OF  THE  ALTERNATE  WBS  EFFECTIVENESS  IN 

IMPLEMENTING  ACQUISITION  REFORM  INITIATIVES 

1.  Streamline  Acquisition/Adoption  of  Commercial 
Practices 

The  alternate  aircraft  system  WBS  allows  implementation 
of  streamlined  acquisition  and  the  adoption  of  commercial 
practices.  As  with  the  baseline  WBS,  it  is  very  difficult 
to  determine  the  effectiveness  of  the  implementation.  Does 
this  alternate  WBS  allow  insight  versus  oversight  and  help 
reduce  cycle-time? 

The  total  number  of  level  2  and  level  3  elements  are 
significantly  reduced  from  fifty-one  elements  with  the 
baseline  WBS  to  thirty-seven  elements  with  the  alternate 
WBS.  This  is  a  twenty-seven  percent  reduction.  This 
results  in  less  data  being  submitted  by  the  contractor. 
Therefore,  one  could  make  the  case  that  since  the  contractor 
is  presenting  less  data,  there  is  less  insight  to  the 
program.  One  should  not  be  concerned  with  how  much  data  are 
being  submitted.  They  should  be  concerned  with  the  quality 
and  usefulness  of  the  data  being  submitted.  The  level  2  and 
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level  3  elements  clearly  depict  the  key  products  and 
processes  that  need  to  be  accomplished  to  allow  the 
objectives  of  an  EMD  program  to  be  successfully  completed. 
Risk  can  be  quantified  and  easily  understood  for  all  the 
elements  in  the  alternate  WBS.  All  level  2  and  3  elements 
are  usually  moderate  to  high-risk  at  the  start  of  an  EMD 
program.  Thus,  the  number  of  elements  decreased  from  the 
baseline  WBS,  but  the  number  of  elements  with  higher  risk 
and  higher  cost  significantly  increased.  This  alternate  WBS 
will  allow  the  PM  to  have  greater  insight  into  the  program 
and  lead  to  early  identification  of  problem  areas.  The  PM 
will  be  able  to  implement  corrective  actions  to  mitigate 
negative  program  impacts . 

The  next  part  of  the  question,  does  the  alternate  WBS 
help  to  reduce  cycle-time,  is  easier  to  address  with  the 
alternate  WBS.  Each  product  and  process  should  be  allocated 
all  requirements  during  the  SEP.  A  tradeoff  conducted  by 
the  Airframe  IPT  will  not  impact  another  component  IPT 
unless  a  requirement  is  breached.  Based  on  experience,  if 
this  is  the  case,  the  breach  or  issue  is  raised  back  to  the 
SEIPT  where  it  is  resolved.  As  with  the  baseline  WBS,  the 
potential  exists  for  no  communication  or  miscommunication, 
but  this  potential  has  been  significantly  reduced.  Thus, 
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the  alternate  WBS  has  the  potential  of  reducing  cycle-time, 
especially  when  compared  to  the  baseline  WBS. 

2.  Integrated  Product  and  Process  Development 
(IPPD) /Integrated  Product  Team  (IPT) 

The  alternate  WBS  is  focused  on  the  key  product  and 
processes  that  need  to  be  accomplished  to  allow  the 
objectives  of  an  EMD  program  to  be  successfully  completed. 
IPTs  are  used  to  focus  on  products  and  processes.  Thus,  the 
alternate  WBS  allows  implementation  of  IPTs.  How 
effectively  are  the  IPTs  structured  within  the  alternate  WBS 
and  does  this  IPT  structure  allow  the  IPPD  process  to  be 
effectively  implemented?  As  with  the  baseline  WBS  analysis, 
another  way  to  ask  this  question  is,  does  this  alternate  WBS 
allow  functional  stovepipes?  The  alternate  WBS 
significantly  reduces  the  potential  for  the  existence  of 
functional  stovepipes.  For  example,  ILS  and  HSI  are  no 
longer  divided  into  several  level  2  elements .  They  are  a 
part  of  the  System  Engineering  and  Integration  element,  as 
well  as  level  4  elements  for  each  product  element. 

Therefore,  the  SEIPT  and  each  product  IPT  are  held 
accountable  (ownership)  for  satisfying  ILS  and  HIS 
requirements .  Each  IPT  member  has  a  say  in  the  IPPD  process 
(Office  of  the  USD(A&T),  1998).  Therefore,  the  probability 
of  a  functional  stovepipe  existing  is  reduced. 
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The  alternate  WBS  is  focused  on  key  products  and 
processes  which  require  a  multi-disciplinary  team  to  develop 
solutions.  Also,  each  of  the  elements  at  level  2  can 
function  as  a  miniature  project  and  use  IPPD  techniques. 
Thus,  this  alternate  WBS  does  allow  for  the  potential  to 
effectively  implement  IPPD  and  IPTs. 

3.  Cost  As  An  Independent  Variable  (CAIV) 

The  alternate  WBS  allows  for  implementation  of  CAIV. 

How  effectively  does  the  alternate  WBS  implement  CAIV?  The 
alternate  WBS  is  focused  on  the  key  products  and  processes 
that  need  to  be  accomplished  to  allow  the  objectives  of  an 
EMD  program  to  be  successfully  completed.  One  can  easily 
establish  a  cost  for  each  element  of  the  alternate  WBS.  All 
tradeoffs  that  affect  cost  are  allocated  to  the  product 
element  or  product  IPT.  The  probability  of  any  tradeoff  or 
decision  impacting  another  product  element  or  IPT  has  been 
significantly  reduced.  Based  on  experience,  if  a  breach 
occurs,  then  the  IPT  raises  it  to  the  SEIPT  to  resolve. 
Therefore,  the  alternate  WBS  significantly  increases  the 
effectiveness  of  CAIV  implementation. 

4.  Total  Ownership  Costs 

Does  the  alternate  WBS  allow  programs  be  managed  to 
optimize  total  system  performance  and  minimize  the  cost  of 
ownership?  The  alternate  WBS  is  focused  on  the  key  products 
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and  processes  that  need  to  be  accomplished  to  allow  the 
objectives  of  an  EMD  program  to  be  successfully  completed. 
Each  product  and  process  should  be  allocated  all 
requirements  during  the  SEP,  which  includes  all  costs 
associated  to  it.  The  costs  include  the  life-cycle  cost  or 
total  ownership  cost .  The  alternate  WBS  allows  the 
requirements  and  costs  to  be  clearly  identified  and 
allocated  to  an  element.  Therefore,  the  alternate  WBS 
allows  total  ownership  costs  to  be  effectively  allocated  and 
used  to  optimize  total  system  performance  and  minimize  the 
cost  of  ownership. 

5.  Performance  Specification 

The  alternate  WBS  allows  the  use  of  performance 
specifications.  The  alternate  WBS  is  focused  on  the  key 
products  and  processes  that  need  to  be  accomplished  to  allow 
the  objectives  of  an  EMD  program  to  be  successfully 
completed.  All  requirements  are  allocated  during  the  SEP  to 
each  of  the  level  2  product  and  process  elements.  Based  on 
experience,  the  SEIPT  maintains  the  interface  control 
documents  for  the  integration  of  products  and  processes.  If 
the  level  2  product  and  process  element  breaches  their 
allocated  requirements,  then  the  issue  is  raised  to  the 
SEIPT  to  resolve.  Based  on  my  experience,  any  level  3 
element  breaches  are  resolved  at  the  respective  level  2 
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element.  If  this  level  3  element  breach  creates  a  level  2 
element  breach,  then  it  is  raised  to  the  SEIPT  to  resolve. 
Thus,  this  allows  performance  specifications  to  be  written 
to  the  elements  in  the  alternate  WBS. 

6.  Earned  Value  Management  System  (EVMS) 

The  alternate  WBS.  allows  implementation  of  the  EVMS  and 
it  allows  adequate  insight  into  the  high-risk  and  high-cost 
areas.  The  alternate  WBS  allows  PMs  to  quickly  determine 
what  they  are  doing,  how  are  they  going  to  do  it,  and  when 
they  are  planning  to  do  it.  The  alternate  WBS  allows  an 
EVMS  to  reflect  IPPD  and  SEP  activities.  Is  the  contractor 
or  are  the  IPTs  applying  the  SEP  and  best  practices  to 
develop  the  end  products?  An  EVMS  based  on  the  alternate 
WBS  will  provide  PMs  with  this  data.  The  alternate  WBS 
significantly  improves  the  use  of  the  EVMS  over  that  of  the 
baseline  WBS. 

The  program  estimates  (cost,  schedule,  performance,  and 
risk)  are  developed  at  the  beginning  of  an  acquisition 
phase.  These  estimates  are  based  on  some  amount  of 
knowledge  and  have  some  degree. of  uncertainty.  As  work  is 
accomplished  during  the  acquisition  phase,  more  knowledge  is 
being  gained  that  decreases  or  increases  the  amount  of 
uncertainty  in  the  estimates .  An  EVMS  based  on  the 
alternate  WBS  will  result  in  some  elements  (projects)  being 
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closed  before  the  end  of  the  program,  similarly  to  work 
packages.  For  example,  the  Airframe  Preliminary  Design 
element  will  be  closed  after  the  PDR  is  conducted.  A  PDR  is 
usually  conducted  after  a  significant  event,  which  is 
normally  some  form  of  a  verification  (test) .  At  PDR  and 
other  key  events,  IPTs  should  re-evaluate  their  program 
estimates.  Usually,  a  significant  amount  of  knowledge  is 
gained  during  a  phase.  This  either  reduces  or  increases  the 
risk  of  the  next  phase,  i.e.,  the  Airframe  Detailed  Design. 
If  a  Monte  Carlo  Simulation  Tool  were  used,  IPTs  will  be 
able  to  review  their  assximptions  and  easily  modify  them  to 
reflect  the  current  program.  These  results  should  be 
reflected  in  the  EVMS.  This  process  will  improve  the 
effectiveness  of  the  EVMS. 

7.  Integrated  Hemagement  Plan  (IMP)  and  Integrated 
Memagement  Schedule  (IMS) 

The  alternate  WBS  allows  implementation  of  the  IMP  and 
IMS.  The  alternate  WBS  allows  the  contractor  to  develop  an 
event-oriented  plan  that  can  be  translated  into  a  detailed, 
time-dependent,  task-oriented  schedule.  How  effectively 
does  the  alternate  WBS  allow  implementation?  Based  on  my 
experience,  the  alternate  WBS  allows  PMs  to  quickly 
determine  what  they  are  doing,  how  are  they  going  to  do  it, 
and  when  they  are  planning  to  do  it.  Based  on  my 
experience,  an  IMP  based  on  the  alternate  WBS  will  be  able 
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to  easily  document  the  significant  accomplishments  that  lead 
to  a  key  program  event,  i.e.,  a  verification  event  (test). 
Therefore,  an  IMP  and  IMS  developed  from  the  alternate  WBS 
does  effectively  implement  an  IMP  and  IMS. 

8.  Alpha  Contracting 

Alpha  Contracting  allows  the  alternate  WBS  to  be 
developed.  Alpha  Contracting  allows  the  Government  and 
contractor  to  jointly  develop  the  alternate  WBS  based  upon 
their  joint  interpretation  of  risks  and  costs,  although, 
there  is  a  potential  for  this  alternate  WBS  to  not  be 
constructed  in  accordance  with  paragraph  G  of  this  chapter. 

9.  Single  Process  Initiative  (SPZ) 

The  SPI  may  not  allow  the  alternate  WBS  to  be 
developed.  If  a  contractor  has  an  approved  procedure  for 
developing  a  WBS  that  is  a  different  concept  than  the 
alternate  WBS  concept,  then  the  alternate  WBS  would  not  be 
developed.  Their  procedure  may  result  in  a  better  or  worse 
WBS.  Again,  the  WBS  may  need  to  be  negotiated  during  the 
solicitation  process  to  ensure  the  Government  and  the 
contractor  will  be  obtaining  useful  data  with  which  to 
manage  and  track  the  contractor's  progress. 

10.  Other  Impacts  Resulting  From  the  Alternate  WBS 

The  alternate  WBS  may  result  in  some  negative  impacts . 

It  will  be  more  difficult  to  determine  the  cost  of  initial 
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spares  and  repair  parts,  common  and  peculiar  support 
equipment,  training,  data,  industrial  facilities,  and 
operational  site  activation.  These  elements  of  the  baseline 
WBS  are  used  to  support  the  DoD  resource  allocation  process 
in  order  to  obtain  the  necessary  funding  to  accomplish 
fielding  and  operation  and  support.  The  information 
required  for  these  elements  is  allocated  and  maintained  at 
the  lower  level  elements  with  the  alternate  WBS.  Financial 
personnel  will  have  to  search  through  the  data  or  have  the 
IPTs  report  it  to  them.  There  may  be  other  negative  impacts 
which  requires  further  analysis.  This  is  beyond  the  scope 
of  this  research. 

I.  SUMMARY 

The  WBS  provides  a  consistent  and  visible  framework  for 
communicating  cost,  schedule,  performance,  and  risk 
management  for  development  of  defense  materiel  items .  The 
WBS  takes  large,  complex,  unmanageable  programs  and  breaks 
them  into  small,  easily-understandable,  and  manageable 
modules.  PMs  need  to  know  what  they  are  doing,  how  are  they 
going  to  do  it,  and  when  they  are  planning  to  do  it.  PMs 
need  insight  into  high-risk  and  high-cost  elements  of  the 
WBS  in  order  to  have  successful  programs.  How  a  WBS  is 
constructed  depends  on  the  perspective  of  the  individual  IPT 
members.  IPTs  use  the  SEP  to  progressively  decompose  or 
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allocate  system  requirements  to  lower  level  products  and 
processes . 

A  baseline  WBS  was  constructed  in  accordance  with  MIL- 
HDBK-881.  The  analysis  concluded  that  this  baseline  WBS 
significantly  impedes  DoD  implementation  of  acquisition 
reform  initiatives.  PMs  and  IPTs  do  not  have  insight  into 
the  high-risk  and  high-cost  elements.  It  is  difficult  to 
determine  what  we  are  doing,  how  are  we  going  to  do  it,  and 
when  are  we  planning  to  do  it.  It  does  not  adequately 
identify  and  differentiate  the  key  products  and  processes 
essential  for  program  success . 

An  alternate  WBS  was  constructed  based  on  the 
analysis  of  the  baseline  WBS.  The  basic  concept  used  to 
develop  the  alternate  method  was  to  focus  on  the  key 
products  and  processes  that  need  to  be  accomplished  to  allow 
the  objectives  of  an  acquisition  phase  to  be  successfully 
completed.  Then  projects  were  identified  for  each  key 
product  and  process  that  needed  to  be  accomplished  to  allow 
the  objectives  of  the  product  or  process  to  be  successfully 
completed  for  an  EMD  program.  This  alternate  WBS  has  the 
potential  to  significantly  facilitate  implementation  of  DoD 
acquisition  reform  initiatives,  although  further  analysis  is 
required  to  determine  all  of  the  impacts. 


96 


V.  CONCLUSIONS  AND  RECOMMENDATIONS 

A.  CONCLUSIONS 

Many  of  the  assertions  and  conclusions  in  this  thesis 
are  based  on  experiences  and  discussions  with  Government  and 
contractor  personnel  during  my  career.  I  have  attempted  to 
implement  many  acquisition  reform  initiatives  and  have  been 
frustrated  by  not  being  able  to  effectively  execute  them. 
Many  of  the  assertions  and  conclusions  in  this  thesis  are  a 
result  of  discussions  during  IPT  meetings  and  an  Alpha 
Contracting  process .  Additionally,  part  of  the  assertions 
and  conclusions  in  this  thesis  are  a  result  of  the  various 
acquisition  and  management  courses  taken  while  attending 
NPS. 

1.  Primary  Question 

To  what  extent  does  MIL-HDBK-881  facilitate  or  impede 

execution  of  acquisition  reform  initiatives? 

MIL-HDBK-881  significantly  impedes  implementation  of 
acquisition  reform  initiatives.  A  WBS  prepared  in 
accordance  with  MIL-HDBK-881  does  not  allow  PMs  and  IPTs  to 
have  insight  into  many  of  the  high-risk  and  high-cost 
elements.  It  is  difficult  to  determine  what  is  being 
planned,  how  it  is  going  to  be  accomplished,  and  when  it 
will  be  completed.  The  WBS  does  not  adequately  identify  and 
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differentiate  the  key  products  and  processes  essential  for 


program  success. 

2 .  Subsidiary  Questions 

a.)  What  acquisition  reform  initiatives  does  the 
WBS  affect? 

The  WBS  affects  the  following  acquisition  reform 
initiatives : 

•  Streamlined  Acquisition/Adoption  of  Commercial 
Practices  (reduce  cycle-time  and  insight  versus 
oversight  management) 

•  Integrated  Product  and  Process  Development 
(IPPD) /Integrated  Product  Team  (IPT) 

•  Cost  As  AN  Independent  Variable  (CAIV) 

•  Total  Ownership  Costs 

•  Performance  Specification 

•  Earned  Value  Management  System  (EVMS) 

•  Integrated  Management  Plan  (IMP)  and  Integrated 
Management  Schedule  ( IMS ) 

•  Alpha  Contracting 

•  Single  Process  Initiative 

b)  What  are  the  possible  uses  of  the  WBS? 

The  WBS  provides  the  basis  for  communication 
throughout  the  acquisition  process.  The  WBS  is  used  for 
program  and  technical  planning,  scheduling,  resource 
allocations,  cost  estimating,  budgeting,  contracting, 
configuration  management,  and  performance  reporting  (EVMS) . 

c)  What  does  the  project  manager  need  to 
consider  when  structuring  a  WBS? 

DoD  acquisition  officials  and  PMs  want  to  have 

successful  programs.  They  require  tools  that  will  allow 
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them  to  provide  the  warfighter  with  an  affordable, 
supportable,  and  operationally-ef fective  and  suitable  system 
at  the  time  when  it  is  needed.  They  want  to  know  what  they 
are  doing,  how  are  they  going  to  do  it,  and  when  they  are 
planning  to  do  it.  They  want  to  ensure  proper  planning  of 
all  tasks  required  to  successfully  meet  the  objectives  of 
the  acquisition  phase.  They  want  to  know  that  best 
practices  are  being  logically  employed  to  make  their  program 
successful.  Additionally,  they  want  to  know  what  are  the 
high-risk  and  high-cost  areas  that  will  require  their 
attention.  The  WBS  is  the  framework  to  allow  PMs  to  quickly 
determine  what  they  are  doing,  how  are  they  going  to  do  it, 
and  when  they  are  planning  to  do  it. 

d)  Is  there  an  alternative  method  (s)  to 

structure  the  WBS  that  will  allow  better 
execution  or  implementation  of  acfjuisition 
reform  initiatives? 

Yes,  there  is  an  alternate  method  to  structure  the 
WBS  that  could  significantly  facilitate  DoD  acquisition 
reform  initiatives  and  increase  the  effectiveness  of  the 
EVMS.  The  basic  concept  used  to  develop  the  alternate 
method  was  to  focus  on  the  key  products  and  processes  that 
need  to  be  accomplished  to  allow  the  objectives  of  an 
acquisition  phase  to  be  successfully  completed.  Then 
projects  were  identified  for  each  key  product  and  process 
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that  needs  to  be  accomplished  to  allow  the  objectives  of  the 
product  or  process  to  be  successfully  completed. 

B.  RECOMMENDATIONS 

1.  Further  Study  and  Analysis  of  Alternate  MBS  Format 

This  thesis  identified  an  alternate  WBS  format.  This 
alternate  WBS  has  the  potential  to  significantly  facilitate 
implementation  of  acquisition  reform  initiatives  and 
significantly  improve  the  EVMS.  This  is  only  a  start.  It 
requires  further  study  and  analysis  to  determine  its 
potential  as  well  as  any  negative  affects.  Both  Government 
and  contractor  PMs  should  be  surveyed  for  their  feedback  on 
this  new  method.  Data  from  a  prior  or  existing  program 
could  be  reformatted  into  the  alternate  WBS  format  and 
determine  if  it  is  more  effective  than  the  actual  WBS  at 
identifying  high-cost  and  high-risk  elements,  and  early 
identification  of  potential  problems. 

2.  Revise  MIL-HDBK-881 

MIL-HDBK-881  contradicts  itself  and  I  found  it 
difficult  to  follow.  It  has  excellent  definitions  of 
various  elements,  but  some  are  confusing.  It  should  be 
revised  by  using  an  IPPD  environment.  Personnel  from  all 
stakeholders  should  be  on  an  IPT,  for  example:  acquisition 
managers,  systems  engineers,  financial  managers, 
comptrollers,  contracting  personnel,  auditors,  etc.  The  IPT 
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should  consist  of  both  Government  and  contractor  personnel. 
Each  of  their  perspectives  is  essential  to  determining  the 
best  technique  to  construct  a  WBS  that  satisfies  all  of 
their  disparate  objectives. 

C.  RECOMMENDATIONS  FOR  FURTHER  STUDY 

1.  Survey  Acquisition  Community 

Both  the  Government  and  contractor  acquisition 
communities  should  be  polled  to  determine  their  opinions  of 
this  alternate  WBS  technique.  They  should  be  surveyed  to 
determine  if  they  have  implementation  problems  with 
executing  acquisition  reform  initiatives  as  well  as  the 
effectiveness  of  their  EVMS.  Additionally,  they  should  be 
questioned  on  any  potential  negative  impacts  this  alternate 
technique  may  create . 

2 .  Convert  Prior  Program  Data 

Data  from  a  prior  or  existing  program  should  be 
reformatted  into  the  alternate  WBS  format  and  determine  if 
it  is  more  effective  than  the  actual  WBS  at  identifying 
high-cost  and  high-risk  elements,  and  early  identification 
of  potential  problems . 
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APPENDIX  A.  AIRCRAFT  SYSTEMS  —  WORK  BREAKDOWN  STRUCTURE 

LEVELS 

(Extracted  from  MIL-HDBK-881) 

A.l.  SCOPE 

This  appendix  provides  the  aircraft  system  work 
breakdown  structure.  Definitions  for  the  aircraft  air 
vehicle  are  provided  in  this  appendix.  Definitions  for  WBS 
elements  common  to  all  defense  materiel  items  are  given  in 
Appendix  H:  Work  Breakdown  Structure  Definitions,  Common 
Elements . 

A.  2.  WORK  BREAKDOWN  STRUCTURE  LEVELS 

Table  A.l.  depicts  the  Aircraft  Systems  WBS  levels. 

A. 3.  DEFINITIONS 

A. 3.1.  Aircraft  System 

The  complex  of  equipment  (hardware /software) ,  data, 
services,  and  facilities  required  to  develop  and  produce  air 
vehicles . 

Includes : 

•  those  employing  fixed,  movable,  rotary,  or  compound 
wing 

•  those  manned /unmanned  air  vehicles  designed  for 
powered  or  unpowered  (glider)  guided  flight 
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Level  1 


Aircraft 

System 


_ Level  2 

Air  Vehicle  (AV) 


Systems 

Engineering/ Program 
Management 


System  Test  and 
Evaluation 


_ _ Level  3 _ 

Airframe 

Propulsion 

AV  Applications  Software 
AV  System  Software 
Communications/ Identification 
Navi gat i on / Gu i dance 
Central  Computer 
Fire  Control 

Data  Display  and  Controls 
Survi vabi 1 i ty 
Reconnaissance 
Automatic  Flight  Control 
Central  Integrated  Checkout 
Antisubmarine  Warfare 
Weapons  Delivery 
Auxiliary  Equipment  Armament 


Development  Test  and  Evaluation 
Operational  Test  and  Evaluation 
Mock-ups 

Test  and  Evaluation  Support 
Test  Facilities 
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Includes: 


airframe,  propulsion,  and  all  other  installed 
equipment 

design,  development,  and  production  of  complete 
units  --  prototype  and  operationally  configured 
units  which  satisfy  the  requirements  of  their 
applicable  specifications,  regardless  of  end  use 

Sub-elements  to  the  air  vehicle  (A. 3. 2.1  -- 
A. 3. 2. 17) 


A. 3. 2.1.  Airframe 

The  assembled  structural  and  aerodynamic 
components  of  the  air  vehicle  that  support  subsystems 
essential  to  designated  mission  requirements. 

Includes,  for  example: 

•  basic  structure  --  wing,  empennage,  fuselage,  and 
associated  manual  flight  control  system 

•  rotary  wing  pylons,  air  induction  system,  thrust 
reversers,  thrust  vector  devices,  starters, 
exhausts,  fuel  management,  inlet  control  system 

•  alighting  gear  —  tires,  tubes,  wheels,  brakes, 
hydraulics,  etc. 

•  secondary  power,  furnishings  —  crew,  cargo, 
passenger,  troop,  etc. 

•  instruments  —  flight,  navigation,  engine,  etc. 

•  environmental  control,  life  support  and  personal 
equipment,  racks,  mounts,  intersystem  cables  and 
distribution  boxes,  etc.,  which  are  inherent  to,  and 
nonseparable  from,  the  assembled  structure 

•  dynamic  systems  --  transmissions,  gear  boxes, 
propellers,  if  not  furnished  as  an  integral  part  of 
the  propulsion  unit 
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•  rotor  group  and  other  equipment  homogeneous  to  the 
airframe 

In  addition  to  the  airframe  structure  and 
subsystems,  this  element  includes: 


Integration,  assembly,  test,  and  checkout: 

Includes: 

•  all  efforts  as  identified  in  Appendix  H:  Work 
Breakdown  Structure  Definitions,  Common 
Elements,  to  provide  the  integration,  assembly, 
test,  and  checkout  of  all  elements  into  the 
airframe  to  form  the  air  vehicle  as  a  whole 

•  all  administrative  and  technical  engineering 
labor  to  perform  integration  of  level  3  air 
vehicle  and  airframe  elements;  development  of 
engineering  layouts;  determination  of  overall 
design  characteristics,  and  determination  of 
requirements  of  design  review 

••  overall  air  vehicle  design  and  producibility 
engineering 

••  detailed  production  design;  acoustic  and 
noise  analysis 

••  loads  analysis;  stress  analysis  on 

interfacing  airframe  elements  and  all 
subsystems 

♦ •  design  maintenance  effort  and  development  of 
functional  test  procedures 

• •  coordination  of  engineering  master  drawings 
and  consultation  with  test  and  manufacturing 
groups 

••  tooling  planning,  design,  and  fabrication  of 
basic  and  rate  tools  and  functional  test 
equipments,  as  well  as  the  maintenance  of 
such  equipment 

• •  production  scheduling  and  expediting 
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••  joining  or  installation  of  structures  such 
as  racks ,  mounts ,  etc . 

••  installation  of  seats,  wiring  ducting, 
engines,  and  miscellaneous  equipment  and 
painting 

••  set  up,  conduct,  and  review  of  testing 

assembled  components  or  subsystems  prior  to 
installation 

•  all  effort  associated  with  the  installation, 
integration,  test,  and  checkout  of  the  avionic 
systems  into  the  air  vehicle  including: 

•  •  design  of  installation  plans 

••  quality  assurance  planning  and  control 
including  material  inspection 

••  installation 

••  recurring  verification  tests 

•  •  integration  with  nonavionics  airframe 

subsystems 

•  ground  checkout  prior  to  flight  test;  production 
acceptance  testing  and  service  review;  quality 
assurance  activities  and  the  cost  of  raw 
materials,  purchased  parts,  and  purchased 
equipment  associated  with  integration  and 
assembly 

Nonrecurring  avionics  system  integration  which  is  associated 
with  the  individual  avionics  equipment  boxes  and  avionics 
software  in  a  functioning  system. 


Includes: 


the  labor  required  to  analyze,  design,  and 
develop  avionics  suite  interfaces  and  establish 
interface  compatibility  with  non-avionics 
support  equipment  systems,  aircraft  systems,  and 
mission  planning  systems 
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♦  drawing  preparation  and  establishment  of 
avionics  interface  equipment  requirements  and 
specifications 

•  technical  liaison  and  coordination  with  the 
military  service,  subcontractors,  associated 
contractors,  and  test  groups 


Excludes: 

•  development,  testing,  and  integration  of 
software  (which  should  be  included  in  air 
vehicle  applications  and  system  software) 

•  avionics  system  testing  (included  in  System  Test 
and  Evaluation)  and  aircraft  systems  engineering 
efforts  (included  in  Systems  Engineering /Program 
Management)  . 

•  all  effort  directly  associated  with  the 
remaining  level  3  WBS  elements 


A. 3. 2, 2.  Propulsion 

That  portion  of  the  air  vehicle  that  pertains  to 
installed  equipment  (propulsion  unit  and  other  propulsion) 
to  provide  power/thrust  to  propel  the  aircraft  through  all 
phases  of  powered  flight. 

Includes r  for  example: 


the  engine  as  a  propulsion  unit  within  itself  (e.g., 
reciprocating,  turbo  with  or  without  afterburner,  or 
other  type  propulsion)  suitable  for  integration  with 
the  airframe 

thrust  reversers,  thrust  vector  devices, 
transmissions,  gear  boxes,  and  engine  control  units, 
if  furnished  as  integral  to  the  propulsion  unit 

other  propulsion  equipment  required  in  addition  to 
the  engine  but  not  furnished  as  an  integral  part  of 
the  engine,  such  as  booster  units 
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•  the  design,  development,  production,  and  assembly 
efforts  to  provide  the  propulsion  unit  as  an  entity 

Excludes: 

•  all  effort  directly  associated  with  the  elements  and 
the  integration,  assembly,  test,  and  checkout  of 
these  elements  into  the  air  vehicle 

•  all  ancillary  equipments  that  are  not  an  integral 
part  of  the  engine  required  to  provide  an 
operational  primary  power  source  —  air  inlets, 
instrioments,  controls,  etc. 


A, 3. 2. 3.  Air  Vehicle  Applications  Software 
Includes,  for  example: 

•  all  the  software  that  is  specifically  produced  for 
the  functional  use  of  a  computer  system  or  multiplex 
data  base  in  the  air  vehicle 

•  all  effort  required  to  design,  develop,  integrate, 
and  checkout  the  air  vehicle  applications  Computer 
Software  Configuration  Items  (CSCIs) 

Excludes: 

•  the  non-software  portion  of  air  vehicle  firmware 
development  and  production  (ref.  ANSI/IEEE  Std 
610.12) 

•  software  that  is  an  integral  part  of  any  specific 
subsystem  and  software  that  is  related  to  other  WBS 
level  2  elements 

Note  1:  If  lower  level  information  can  be  collected,  use 
the  structure  and  definitions  in  Appendix  B, 
Electronic /Automated  Software  Systems. 


A. 3. 2. 4.  Air  Vehicle  System  Software 

That  software  designed  for  a  specific  computer 
system  or  family  of  computer  systems  to  facilitate  the 
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operation  and  maintenance  of  the  computer  system  and 
associated  programs  for  the  air  vehicle. 

Includes,  for  example: 

•  operating  systems  —  software  that  controls  the 
execution  of  programs 

•  compilers  —  computer  programs  used  to  translate 
higher  order  language  programs  into  relocatable  or 
absolute  machine  code  equivalents 

•  utilities  —  computer  programs  or  routines  designed 
to  perform  the  general  support  function  required  by 
other  application  software,  by  the  operating  system, 
or  by  system  users  (ref.  ANSI /IEEE  Std  610.12) 

•  all  effort  required  to  design,  develop,  integrate, 
and  checkout  the  air  vehicle  system  software 
including  all  software  developed  to  support  any  air 
vehicle  applications  software  development 

•  air  vehicle  system  software  required  to  facilitate 
development,  integration,  and  maintenance  of  any  air 
vehicle  software  build  and  CSCI 

Excludes: 

•  all  software  that  is  an  integral  part  of  any 
specific  subsystem  specification  or  specifically 
designed  and  developed  for  system  test  and 
evaluation 

•  software  that  is  an  integral  part  of  any  specific 
subsystem,  and  software  that  is  related  to  other  WBS 
level  2  elements 

Note  1:  If  lower  level  information  can  be  collected,  use 
the  structure  and  definitions  in  Appendix  B, 
Electronic /Automated  Software  Systems, 
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A. 3. 2. 5.  Communications /Identification 

That  equipment  (hardware/ software)  installed  in 
the  air  vehicle  for  communications  and  identification 
purposes . 

Includes,  for  example: 

•  intercoms,  radio  system (s) ,  identification  equipment 
(IFF),  data  links,  and  control  boxes  associated  with 
the  specific  equipment 

•  integral  communication,  navigation,  and 
identification  package  (if  used) 

Note  2:  All  effort  directly  associated  with  the 
remaining  level  3  WBS  elements  and  the 
integration,  assembly,  test,  and  checkout  of 
these  elements  into  the  air  vehicle  is  excluded. 
This  item  contains  embedded  software  —  software 
defined  in  the  item  specification  and  provided 
by  the  supplier. 


A. 3. 2.  6.  Navigation/Guidance 

That  equipment  (hardware /software)  installed  in 
the  air  vehicle  to  perform  the  navigational  guidance 
function. 

Includes: 

•  radar,  radio,  or  other  essential  navigation 

equipment,  radar  altimeter,  direction  finding  set, 
doppler  compass,  computer,  and  other  equipment 
homogeneous  to  the  navigation/guidance  function 

Note  1:  If  lower  level  information  can  be  collected,  use 
the  structure  and  definitions  in  Appendix  B, 
Electronic/Automated  Software  Systems. 

Note  2:  All  effort  directly  associated  with  the 
remaining  level  3  NBS  elements  and  the 
integration,  assembly,  test,  and  checkout  of 
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these  elements  into  the  air  vehicle  is  excluded. 
This  item  contains  embedded  software  —  software 
defined  in  the  item  specification  and  provided 
by  the  supplier. 


A.3.2.7 .  Central  Ccmputer 

The  master  data  processing  unit(s)  responsible  for 
coordinating  and  directing  the  major  avionic  mission 
systems. 

JNbte  1:  If  lower  level  information  can  be  collected,  use 
the  structure  and  definitions  in  Appendix  B, 
Electronic/Automated  Software  Systems. 

Note  2i  All  effort  directly  associated  with  the 
remaining  level  3  WBS  elements  and  the 
integration,  assembly,  test,  and  checkout  of 
these  elements  into  the  air  vehicle  is  excluded. 
This  item  contains  embedded  software  —  software 
defined  in  the  item  specification  and  provided 
by  the  supplier. 

A. 3. 2. 8.  Fire  Control 

That  equipment  (hardware/software)  installed  in 
the  air  vehicle  which  provides  the  intelligence  necessary 
for  weapons  delivery  such  as  bombing,  launching,  and  firing. 

Includes,  for  example: 

•  radars  and  other  sensors  including  radomes 

•  apertures /antennas,  if  integral  to  the  fire  control 
system,  necessary  for  search,  target  identification, 
rendezvous  and/or  tracking 

•  self-contained  navigation  and  air  data  systems  • 

•  dedicated  displays,  scopes,  or  sights 

•  bombing  computer  and  control  and  safety  devices 
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Note  1:  If  lower  level  information  can  be  collected,  use 
the  structure  and  definitions  in  Appendix  B, 
Electronic /Automated  Software  Systems. 

Note  2:  All  effort  directly  associated  with  the 
remaining  level  3  WBS  elements  and  the 
integration,  assembly,  test,  and  checkout  of 
these  elements  into  the  air  vehicle  is  excluded. 
This  item  contains  embedded  software  —  software 
defined  in  the  item  specification  and  provided 
by  the  supplier. 

A. 3. 2. 9.  Data  Display  and  Controls 

The  equipment  (hardware /software)  which  visually 
presents  processed  data  by  specially  designed  electronic 
devices  through  interconnection  (on-or  off-line)  with 
computer  or  component  equipment  and  the  associated  equipment 
needed  to  control  the  presentation  of  the  data  necessary 
flight  and  tactical  information  to  the  crew  for  efficient 
management  of  the  aircraft  during  all  segments  of  the 
mission  profile  under  day  and  night  all-weather  conditions. 
Includes,  for  example: 

•  multi-function  displays,  control  display  units, 
display  processors,  and  on-board  mission  planning 
systems 


Excludes : 


•  indicators  and  instrxaments  not  controlled  by 

keyboard  via  the  multiplex  data  bus  and  panels  and 
consoles  which  are  included  under  the  airframe 

Note  1:  If  lower  level  information  can  be  collected,  use 
the  structure  and  definitions  in  Appendix  B, 
Electronic/Automated  Software  Systems. 
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Note  2:  All  effort  directly  associated  with  the 
remaining  level  3  WBS  elements  and  the 
integration,  assembly,  test,  and  checkout  of 
these  elements  into  the  air  vehicle  is  excluded. 
This  item  contains  embedded  software  —  software 
defined  in  the  item  specification  and  provided 
by  the  supplier. 


A. 3. 2. 10.  Survivability 

Those  equipments  (hardware /software)  installed  in, 
or  attached  to,  the  air  vehicle  which  assist  in  penetration 
for  mission  accomplishment. 

Includes,  for  example: 

•  ferret  and  search  receivers,  warning  devices  and 
other  electronic  devices,  electronic 
countermeasures,  jamming  transmitters,  chaff,  infra¬ 
red  jammers,  terrain-following  radar,  and  other 
devices  typical  of  this  mission  function 

Note  1:  If  lower  level  information  can  be  collected,  use 
the  structure  and  definitions  in  Appendix  B, 
Electronic /Automated  Software  Systems. 

Note  2:  All  effort  directly  associated  with  the 
remaining  level  3  WBS  elements  and  the 
integration,  assembly,  test,  and  checkout  of 
these  elements  into  the  air  vehicle  is  excluded. 
This  item  contains  embedded  software  —  software 
defined  in  the  item  specification  and  provided 
by  the  supplier. 


A. 3. 2. 11.  Reconnaissance 

Those  equipments  {hardware/software)  installed  in, 
or  attached  to,  the  air  vehicle  necessary  to  the 
reconnaissance  mission. 

Includes,  for  example: 
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•  photographic,  electronic,  infrared,  and  other 

sensors 

•  search  receivers 

•  recorders 

•  warning  devices 

•  magazines 

•  data  link 

Excludes: 

•  gun  cameras 

Note  1:  If  lower  level  information  can  be  collected,  use 
the  structure  and  definitions  in  Appendix  B, 
Electronic/Automated  Software  Systems, 

Note  2:  All  effort  directly  associated  with  the 
remaining'  level  3  WBS  elements  and  the 
integration,  assembly,  test,  and  checkout  of 
these  elements  into  the  air  vehicle  is  excluded. 
This  item  contains  embedded  software  —  software 
defined  in  the  item  specification  and  provided 
by  the  supplier, 

A, 3, 2, 12,  Automatic  Flight  Control 

Those  electronic  devices  and  sensors,  which,  in 
combination  with  the  flight  controls  subsystem  (under 
airframe) ,  enable  the  crew  to  control  the  flight  path  of  the 
aircraft  and  provide  lift,  drag,  trim,  or  conversion 
effects . 

Includes,  for  example: 

•  flight  control  computers,  software,  signal 
processors,  and  data  transmitting  elements  that  are 
devoted  to  processing  data  for  either  primary  or 
automatic  flight  control  functions 

•  electronic  devices  required  for  signal  processing, 
data  formatting,  and  interfacing  between  the  flight 
control  elements;  the  data  buses,  optical  links,  and 


115 


other  elements  devoted  to  transmitting  flight 
control  data 

•  flight  control  sensors  such  as  pressure  transducers, 
rate  gyros,  accelerometers,  and  motion  sensors 


Excludes: 

*  devices  —  linkages,  control  surfaces,  and  actuating 
devices  —  covered  under  the  airframe  WBS  element 

•  avionics  devices  and  sensors  --  central  computers, 
navigation  computers,  avionics  data  buses  and 
navigation  sensors  —  which  are  included  under  other 
avionics  WBS  elements 

Note  1:  If  lower  level  information  can  be  collected,  use 
the  structure  and  definitions  in  Appendix  B, 
Electronic /Automated  Software  Systems. 

Note  2:  All  effort  directly  associated  with  the 
remaining  level  3  WBS  elements  and  the 
integration,  assembly,  test,  and  checkout  of 
these  elements  into  the  air  vehicle  is  excluded. 
This  item  contains  embedded  software  —  software 
defined  in  the  item  specification  and  provided 
by  the  supplier. 


A. 3. 2. 13.  Central  Integrated  Checkout 

That  equipment  (hardware /software)  installed  in 
the  air  vehicle  for  malfunction  detection  and  reporting. 

Note  1:  If  lower  level  information  can  be  collected,  use 
the  structure  and  definitions  in  Appendix  B, 
Electronic/Automated  Software  Systems. 

Note  2:  All  effort  directly  associated  with  the 
remaining  level  3  WBS  elements  and  the 
integration,  assembly,  test,  and  checkout  of 
these  elements  into  the  air  vehicle  is  excluded. 
This  item  contains  embedded  software  —  software 
defined  in  the  item  specification  and  provided 
by  the  supplier. 
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A, 3 ,2 .14.  Antiaulmarine  Warfare 

That  equipment  (hardware /software)  installed  in 
the  air  vehicle  peculiar  to  the  antisubmarine  warfare 
mission. 

Includes,  for  example: 

•  sensors,  computers,  displays,  etc. 

Note  1:  If  lower  level  information  can  be  collected,  use 
the  structure  and  definitions  in  Appendix  B, 
Electronic /Automated  Software  Systems. 

Note  2:  All  effort  directly  associated  with  the 
remaining  level  3  WBS  elements  and  the 
integration,  assembly,  test,  and  checkout  of 
these  elements  into  the  air  vehicle  is  excluded. 
This  item  contains  embedded  software  —  software 
defined  in  the  item  specification  and  provided 
by  the  supplier. 


A. 3. 2. 15.  Armament 

That  equipment  (hardware /software)  installed  in 
the  air  vehicle  to  provide  the  firepower  functions . 

Includes,  for  example; 

•  guns,  high  energy  weapons,  mounts,  turrets,  weapon 
direction  equipment,  ammunition  feed  and  ejection 
mechanisms,  and  gun  cameras 

Note  1:  If  lower  level  information  can  be  collected,  use 
the  structure  and  definitions  in  Appendix  B, 
Electronic /Aut^uated  Software  Systems. 

Note  2:  All  effort  directly  associated  with  the 
remaining  level  3  WBS  elements  and  the 
integration,  assembly,  test,  and  checkout  of 
these  elements  into  the  air  vehicle  is  excluded. 
This  item  contains  embedded  software  —  software 
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defined  in  the  item  specification  and  provided 
by  the  supplier. 


A. 3. 2. 16.  Weapons  Delivery 

That  equipment  (hardware /software)  installed  in 
the  air  vehicle  to  provide  the  weapons  delivery  capability. 

Includes,  for  example; 

•  launchers,  pods,  bomb  racks,  pylons,  integral 
release  mechanisms,  and  other  mechanical  or  electro¬ 
mechanical  equipments  specifically  oriented  to  the 
weapons  delivery  function 

Excludes: 

•  bombing/navigation  system  (included  in  the  fire 
control  element) 

Note  1:  If  lower  level  information  can  be  collected,  use 
the  structure  and  definitions  in  Appendix  B, 
Electronic/Automated  Software  Systems. 

Note  2:  All  effort  directly  associated  with  the 
remaining  level  3  WBS  elements  and  the 
integration,  assembly,  test,  and  checkout  of 
these  elements  into  the  air  vehicle  is  excluded. 
This  item  contains  embedded  software  —  software 
defined  in  the  item  specification  and  provided 
by  the  supplier. 


A. 3 .2.17 .  Auxiliary  Equipment 

Auxiliary  airframe,  electronics,  and/or 
armament /weapons  delivery  equipment  not  allocable  to 
individual  element  equipments,  or  which  provides  the 
ancillary  functions  to  the  applicable  mission  equipments. 

Includes,  for  example: 
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•  auxiliary  airframe  equipment  such  as  external  fuel 
tanks,  pods,  and  rotodomes 

•  multi-use  equipment  like  antennas,  control  boxes, 
power  supplies,  environmental  control,  racks,  and 
mountings,  not  homogeneous  to  the  prescribed  WBS 
elements 

Note  1:  If  lower  level  information  can  be  collected,  use 
the  structure  and  definitions  in  Appendix  B, 
Electronic /Automated  Software  Systems. 

Note  2:  All  effort  directly  associated  with  the 
remaining  level  3  WBS  elements  and  the 
integration,  assembly,  test,  and  checkout  of 
these  elements  into  the  air  vehicle  is  excluded. 
This  item  contains  embedded  software  —  software 
defined  in  the  item  specification  and  provided 
by  the  supplier. 

Note  3:  Auxiliary  armament /weapons  delivery  equipment 

includes  flares  and  ejection  mechanisms,  ejector 
cartridges,  and  other  items  peculiar  to  the 
mission  function  that  are  not  identifiable  to 
the  armament  or  weapons  delivery  elements  set 
forth  in  A. 4. 2. 15  and  A. 4. 2. 16  of  this  appendix. 

A. 3  *  3 .  Common  Elements 

WBS  Levels  2  and  3 .  ■  Definitions  for  common  WBS 
elements  applicable  to  the  aircraft  as  well  as  all  other 
defense  materiel  items  are  in  Appendix  H:  Work  Breakdown 
Structure  Definitions,  Common  Elements. 
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WORK 


APPENDIX  B.  ELECTRONIC /AUTOMATED  SOFTWARE  SYSTEMS  — 

BREAKDOWN  STRUCTURE  LEVELS 

(Extracted  from  MIL-HDBK-881) 


Level  1 

Level  2 

Level  3 

Electronic/ 

Automated 

Software 

System 

Prime  Mission  Product 
(PMP) 

Subsystem  l..n  (Specify  Names) 

PMP  Applications  Software 

PMP  System  Software 

Integration,  Assembly,  Test  and  Checkout 

Platform  Integration 

Systems 

Engineering/ Program 
Management 

System  Test  and 
Evaluation 

Development  Test  and  Evaluation 
Operational  Test  and  Evaluation 

Mock-ups 

Test  and  Evaluation  Support 

Test  Facilities 

Training 

Equipment 

Services 

Facilities 

Data 

Technical  Publications 

Engineering  Data 

Management  Data 

Support  Data 

Data  Depository 

Peculiar  Support 
Equipment 

Test  and  Measurement  Equipment 

Support  and  Handling  Equipment 

Common  Support 
Equipment 

Test  and  Measurement  Equipment 

Support  and  Handling  Equipment 

Operational / Site 
Activation 

System  Assembly,  Installation  and 

Checkout  on  Site 

Contractor  Technical  Support 

Site  Construction 

Site/Ship/Vehicle  Conversion 

Industrial  Facilities 

Construction/Conversion/Expansion 
Equipment  Acquisition  or  Modernization 
Maintenance  (Industrial  Facilities) 

Initial  Spares  and 
Repair  Parts 

Table  B.l.  Electronic/Automated  Software  Systems  WBS  (Extracted  from  MIL-STD-881) 
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APPENDIX  C.  MISSILE  SYSTEM  —  WORK  BREAKDOWN  STRUCTURE 

LEVELS 

_ (Extracted  from  MIL-HDBK-881) 


Level  1 

Level  2 

Level  3 

Missile 

System 

Air  Vehicle 

Propulsion  (Stages  I..n,] 

Payload 

Airframe 

Reentry  System 

Post  Boost  System 

Guidance  and  Control 

Ordnance  Initiation  Set 

Airborne  Test  Equipment 

Airborne  Training  Equipment 

Auxiliary  Equipment 

Integration,  Assembly,  Test  and  Checkout 

Command  and  Launch 

Surveillance,  Identification  and 

Tracking  Sensors 

Launch  and  Guidance  Control 

Communications 

Command  and  Launch  Applications 

Software 

Command  and  Launch  System 

Software 

Launcher  Equipment 

Auxiliary  Equipment 

Systems  Engineering/ 
Program  Management 

System  Test  and 
Evaluation 

Development  Test  and  Evaluation 
Operational  Test  and  Evaluation 

Mock-ups 

Test  and  Evaluation  Support 

Test  Facilities 

Training 

Equipment 

Services 

Facilities 

Data 

Technical  Publications 

Engineering  Data 

Management  Data 

Support  Data 

Data  Depository 

Peculiar  Support 
Equipment 

Test  and  Measurement  Equipment 

Support  and  Handling  Equipment 

Common  Support 
Equipment 

Test  and  Measurement  Equipment 

Support  and  Handling  Equipment 

Operational /Site 
Activation 

System  Assembly,  Installation  and 

Checkout  on  Site 

Contractor  Technical  Support 

Site  Construction 

Site/Ship/Vehicle  Conversion 

Industrial  Facilities 

Construction/Conversion/Expansion 

Equipment  Acquisition  or  Modernization 
Maintenance  (Industrial  Facilities) 

Initial  Spares  and 
Repair  Parts 

Table  C.l.  Missle  System  WBS  (Extracted  from  MIL-STD-881) 
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APPENDIX  D.  ORDNANCE  SYSTEM  —  WORK  BREAKDOWN  STRUCTURE 

LEVELS 

(Extracted  from  MIL-HDBK-881) 


Level  1 

Level  2 

Level  3 

Ordnance 

System 

Complete  Round 

Structure 

Payload 

Guidance  and  Control 

Fuze 

Safety/Arm 

Propulsion 

Integration,  Assembly,  Test  and  Checkout 

Launch  System 

Launcher 

Carriage 

Fire  Control 

Ready  Magazine 

Adapter  Kits 

Integration,  Assembly,  Test  and  Checkout 

Systems  Engineering/ 
Program  Management 

System  Test  and 
Evaluation 

Development  Test  and  Evaluation 
Operational  Test  and  Evaluation 

Mock-ups 

Test  and  Evaluation  Support 

Test  Facilities 

Training 

Equipment 

Services 

Facilities 

Data 

Technical  Publications 

Engineering  Data 

Management  Data 

Support  Data 

Data  Depository 

Peculiar  Support 
Equipment 

Test  and  Measurement  Equipment 

Support  and  Handling  Equipment 

Common  Support 
Equipment 

Test  and  Measurement  Equipment 

Support  and  Handling  Equipment 

Operational /Site 
Activation 

System  Assembly,  Installation  and 

Checkout  on  Site 

Contractor  Technical  Support 

Site  Construction 

Site/Ship/Vehicle  Conversion 

Industrial  Facilities 

C  on  s  t  r uc  t i on / C onver s i on / Expans i on 
Equipment  Acquisition  or  Modernization 
Maintenance  ( Industrial  Facilities ) 

Initial  Spares  and 
Repair  Parts 

Table  D.l.  Ordnance  Systenj  WBS  (Extracted  from  MIL-STD-881) 
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APPENDIX  E.  SHIP  SYSTEMS  —  WORK  BREAKDOWN  STRUCTURE  LEVEL 

(Extracted  from  MIL-HDBK-881) 


Level  1 

Level  2 

Level  3 

Ship  System 

Ship 

Hull  Structure 

Propulsion  Plant 

Electric  Plant 

Command  and  Surveillance 

Auxiliary  Systems 

Outfit  and  Furnishings 

Armament 

Integration/ Engineering 

Ship  Assembly  and  Support  Services 

Systems  Engineering/ 
Program  Management 

System  Test  and 
Evaluation 

Development  Test  and  Evaluation 
Operational  Test  and  Evaluation 

Mock-ups 

Test  and  Evaluation  Support 

Test  Facilities 

Training 

Equipment 

Services 

Facilities 

Data 

Technical  Publications 

Engineering  Data 

Management  Data 
'  Support  Data 

Data  Depository 

Peculiar  Support 
Equipment 

Test  and  Measurement  Equipment 

Support  and  Handling  Equipment 

Common  Support 
Equipment 

Test  and  Measurement  Equipment 

Support  and  Handling  Equipment 

Operational /Site 
Activation 

System  Assembly,  Installation  and 

Checkout  on  Site 

Contractor  Technical  Support 

Site  Construction 

Site/Ship/Vehicle  Conversion 

Industrial  Facilities 

C  ons  t r uc  t i on / Conver  s i on / Expan s i on 

Equipment  Acquisition  or  Modernization 
Maintenance  (Industrial  Facilities) 

Initial  Spares  and 
Repair  Parts 

Table  E.I.  Ship  Systems  WBS  (Extracted  from  MIL-STD-881) 
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APPENDIX  F.  SPACE  SYSTEMS  —  WORK  BREAKDOWN  STRUCTURE  LEVEL 

(Extracted  from  MIL-HDBK-881) 


Level  1 

Level  2 

Level  3 

Space 

System 

Launch  Vehicle 

Propulsion  (Single  Stage  Only) 

Stage  I 

Stage  II.. n  (As  Required) 

Strap-On  Units  (As  Required) 

Shroud  (Payload  Fairing) 

Guidance  and  Control 

Integration,  Assembly,  Test  and  Checkout 

Orbital  Transfer 
Vehicle 

Propulsion  (Single  Stage  Only) 

Stage  I 

Stage  II., n  (As  Required) 

Strap-On  Units  (As  Required) 

Guidance  and  Control 

Integration,  Assembly,  Test  and  Checkout 

Space  Vehicle 

Spacecraft 

Payload  I..n  (As  Required) 

Reentry  Vehicle 

Orbit  In jector /Dispenser 

Integration,  Assembly,  Test  and  Checkout 

Ground  Command, 

Control, 

Communications  and 
Mission  Equipment 

Sensor  I..n  (As  Required) 

Telemetry,  Tracking  and  Control 

External  Communications 

Data  Processing  Equipment 

Launch  Equipment 

Auxiliary  Equipment 

Flight  Support 
Operations  and 

Services 

Ma t e / Checkou t / Launch 

Mission  Control 

Tracking  and  C^ 

Recovery  Operations  and  Services 

Launch  Site  Maintenance /Refurbishment 

Storage 

Planning  and  Preparation 

Storage 

Transfer  and  Transportation 

Systems 

Engineering/ Program 
Management 

System  Test  and 
Evaluation 

Development  Test  and  Evaluation 

Operational  Test  and  Evaluation 

Mock-ups 

Test  and  Evaluation  Support 

Test  Facilities 

Training 

Equipment 

Services 

Facilities 

Data 

Technical  Publications 

Engineering  Data 

Management  Data 

Support  Data 

Data  Depository 

Peculiar  Support 
Equipment 

Test  and  Measurement  Equipment 

Support  and  Handling  Equipment 
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Coinmon  Support 
Equipment 

Test  and  Measurement  Equipment 

Support  and  Handling  Equipment 

Operational /Site 
Activation 

System  Assembly,  Installation  and 
Checkout  on  Site 

Contractor  Technical  Support 

Site  Construction 

Site/Ship/Vehicle  Conversion 

Industrial  Facilities 

Cons  true  t ion/Conver s i on/ Expans i on 
Equipment  Acquisition  or  Modernization 
Maintenance  { Industrial  Facilities ) 

Initial  Spares  and 
Repair  Parts 

Table  E.I.  Space  Systems  WBS  (Extracted  from  MIL-STD-881) 
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WORK  BREAKDOWN 


APPENDIX  6.  SURFACE  VEHICLE  SYSTEMS  -- 

STRUCTURE  LEVEL 

(Extracted  from  MIL-HDBK-881) 


Level  1 

Level  2 

Level  3 

Surface 

Vehicle 

System 

Primary  Vehicle 

Hull /Frame 

Suspension/Steering 

Power  Package /Drive  Train 

Auxiliary  Automotive 

Turret  Assembly 

Fire  Control 

Armament 

Body/Cab 

Automatic  Loading 

Automatic /Remote  Piloting 

Nuclear,  Biological,  Chemical 

Special  Equipment 

Navigation 

Communications 

Integration,  Assembly,  Test  and 

Secondary  Vehicle 

(Same  as  Primary  Vehicle) 

Systems  Engineering/ 
Program  Management 

System  Test  and 
Evaluation 

Development  Test  and  Evaluation 
Operational  Test  and  Evaluation 

Mock-ups 

Test  and  Evaluation  Support 

Test  Facilities 

Training 

Equipment 

Services 

Facilities 

Data 

Technical  Publications 

Engineering  Data 

Management  Data 

Support  Data 

Data  Depository 

Peculiar  Support 
Equipment 

Test  and  Measurement  Equipment 

Support  and  Handling  Equipment 

Common  Support 
Equipment 

Test  and  Measurement  Equipment 

Support  and  Handling  Equipment 

Operational /Site 
Activation 

System  Assembly,  Installation  and 

Checkout  on  Site 

Contractor  Technical  Support 

Site  Construction 

Site/Ship/Vehicle  Conversion 

Industrial  Facilities 

Construction/Conversion/Expansion 
Equipment  Acquisition  or  Modernization 
Maintenance  { Industrial  Facilities ) 

Initial  Spares  and 
Repair  Parts 

Table  G.l.  Surface  Vehicle  Systems  WBS  (Extracted  from  MIL-STD-881) 
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APPENDIX  H.  COMMON  ELEMENTS  —  WORK  BREAKDOWN  STRUCTURE  AND 

DEFINITIONS 

(Extracted  from  MIL-HDBK-881) 

H.l.  SCOPE 

This  appendix  provides  the  WBS  elements  common  to  all 
types  of  systems.  Definitions  for  the  common  WBS  elements 
are  provided  in  this  appendix. 

H.2.  DEFINITIONS 

H.2.1.  Integration,  Assembly,  Test,  and  Checkout 

In  those  instances  in  which  an  integration,  assembly, 
test,  and  checkout  element  is  used  (Appendices  A  through  G) , 
this  element  includes  all  effort  of  technical  and  functional 
activities  associated  with  the  design,  development,  and 
production  of  mating  surfaces,  structures,  equipment,  parts, 
materials,  and  software  required  to  assemble  the  level  3 
equipment  (hardware /software)  elements  into  a  level  2 
mission  equipment  (hardware/software)  as  a  whole  and  not 
directly  part  of  any  other  individual  level  3  element. 
Includes: 

•  the  development  of  engineering  layouts, 
determination  of  overall  design  characteristics,  and 
determination  of  requirements  of  design  review 

•  the  set  up,  conduct,  and  review  of  testing  assembled 
components  or  subsystems  prior  to  installation 

•  the  detailed  production  design,  producibility 
engineering  planning  (PEP) ,  and  manufacturing 
process  capability,  including  the  process  design 
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development  and  demonstration  effort  to  achieve 
compatibility  with  engineering  requirements  and  the 
ability  to  produce  economically  and  consistent 
quality 

•  inspection  activities  related  to  receiving,  factory 
and  vendor  liaison 

•  design  maintenance  effort 

•  quality  planning  and  control 

•  tooling  (initial  production  facilities,  factory 
support  equipment)  including  planning,  design,  and 
fabrication 

•  administrative  engineering 

•  the  joining  or  mating  and  final  assembly  of  level  3 
equipment  elements  to  form  a  complete  prime  mission 
equipment  when  the  effort  is  performed  at  the 
manufacturing  facility 

•  integration  of  software  (including  loading  and 
verification  of  firmware) 

•  conduct  of  production  acceptance  testing 

Excludes s 

•  all  systems  engineering /program  management  and 
system  test  and  evaluation  which  are  associated  with 
the  overall  system 

Note:  When  an  integration,  assembly,  test,  and 

checkout  element  is  utilized  at  lower  levels  of 
the  contract  WBS,  it  will  be  summarized  into  the 
next  higher  level  equipment  (hardware/ software) 
WBS  element  and  should  never  be  summarized 
directly  into  a  level  3  integration,  assembly, 
test,  and  checkout  element. 

H.2.2.  Systems  Engineering/Program  Management 

The  systems  engineering  and  technical  control  as  well 
as  the  business  management  of  particular  systems  and 
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programs.  Systems  engineering /program  management  elements 
to  be  reported  and  their  levels  will  be  specified  by  the 
requiring  activity. 

Includes : 

•  the  overall  planning,  directing,  and  controlling  of 
the  definition,  development,  and  production  of  a 
system  or  program  including  supportability  and 
acquisition  logistics,  e.g.,  maintenance  support, 
facilities,  personnel,  training,  testing,  and 
activation  of  a  system 

Excludes: 


systems  engineering /program  management  effort  that 
can  be  associated  specifically  with  the  equipment 
(hardware /software)  element 


H,2 ,2 , 1 ,  Systems  Engineering 

The  technical  and  management  efforts  of  directing 
and  controlling  a  totally  integrated  engineering  effort  of  a 
system  or  program. 

Includes  but  not  limited  to: 

•  effort  to  define  the  system  and  the  integrated 
pls-nning  and  control  of  the  technical  program 
efforts  of  design  engineering,  specialty 
engineering,  production  engineering,  and 
integrated  test  planning 

•  effort  to  transform  an  operational  need  or 
statement  of  deficiency  into  a  description  of 
system  requirements  and  a  preferred  system 
configuration 

•  technical  planning  and  control  effort  for 
planning,  monitoring,  measuring,  evaluating, 
directing,  and  replanning  the  management  of  the 
technical  program 
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•  (all  programs,  where  applicable)  value 
engineering,  configuration  management,  human 
factors,  maintainability,  reliability, 
survivability/vulnerability,  system  safety, 
environmental  protection,  standardization, 
system  analysis,  logistic  support  analysis,  etc. 

•  (for  ships)  the  extended  Ship  WBS  (ESWBS) , 
Configuration  Management  (811)  ,  Hiiman  Factors 
(892),  Standardization  (893),  Value  Engineering 
(894),  and  Reliability  and  Maintainability  (895) 
elements 

Excludes: 

•  actual  design  engineering  and  the  production 
engineering  directly  related  to  the  WBS  element 
with  which  it  is  associated 

Examples  of  syst&ns  engineering  efforts  are: 

1)  System  definition,  overall  system  design,  design 
integrity  analysis,  system  optimization, 
system/cost  effectiveness  analysis,  and  intra¬ 
system  and  inter-system  compatibility  assurance, 
etc.;  the  integration  and  balancing  of 
reliability,  maintainability,  producibility, 
safety,  human  health,  environmental  protection, 
and  survivability;  security  requirements, 
configuration  management  and  configuration 
control;  quality  assurance  program,  value 
engineering,  preparation  of  equipment  and 
component  performance  specifications,  design  of 
test  and  demonstration  plans;  determination  of 
software  development  or  software  test 
facility/environment  requirements. 

2)  Preparation  of  the  Systems  Engineering 
Management  Plan  (SEMP) ,  specification  tree, ^ 
program  risk  analysis,  system  planning,  decision 
control  process,  technical  performance 
measurement,  technical  reviews,  subcontractor 
and  vendor  reviews,  work  authorization,  and 
technical  documentation  control. 

3)  Reliability  engineering  —  the  engineering 
process  and  series  of  tasks  required  to  examine 
the  probability  of  a  device  or  system  performing 
its  mission  adequately  for  the  period  of  time 


136 


intended  under  the  operating  conditions  expected 
to  be  encountered. 

4)  Maintainability  engineering  --  the  engineering 
process  and  series  of  tasks  required  to  measure 
the  ability  of  an  item  or  system  to  be  retained 
in  or  restored  to  a  specified  condition  of 
readiness,  skill  levels,  etc.,  using  prescribed 
procedures  and  resources  at  specific  levels  of 
maintenance  and  repair. 

5)  Human  factors  engineering  —  the  engineering 
process  and  the  series  of  tasks  required  to 
define,  as  a  comprehensive  technical  and 
engineering  effort,  the  integration  of  doctrine, 
manpower,  and  personnel  integration,  materiel 
development,  operational  effectiveness,  human 
characteristics,  skill  capabilities,  training, 
manning  implication,  and  other  related  elements 
into  a  comprehensive  effort. 

6)  Supportability  analyses  —  an  integral  part  of 
the  systems  engineering  process  beginning  at 
program  initiation  and  continuing  throughout 
program  development.  Supportability  analyses 
form  the  basis  for  related  design  requirements 
included  in  the  system  specification  and  for 
subsequent  decisions  concerning  how  to  most  cost 
effectively  support  the  system  over  its  entire 
life-cycle.  Programs  allow  contractors  the 
maximum  flexibility  in  proposing  the  most 
appropriate  supportability  analyses. 


11.2.2.2,  Program  Management 

The  business  and  administrative  planning, 
organizing,  directing,  coordinating,  controlling,  and 
approval  actions  designated  to  accomplish  overall  program 
objectives  which  are  not  associated  with  specific  hardware 
elements  and  are  not  included  in  systems  engineering. 
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Includes  for  example: 

•  cost,  schedule,  performance  measurement  management, 
warranty  administration,  contract  management,  data 
management,  vendor  liaison,  subcontract  management, 
etc . 

•  support  element  management,  defined  as  the  logistics 
tasks  management  effort  and  technical  control,  and 
the  business  management  of  the  support  elements. 

The  logistics  management  function  encompasses  the 
support  evaluation  and  supportability  assurance 
required  to  produce  an  affordable  and  supportable 
defense  materiel  system 

•  planning  and  management  of  all  the  functions  of 
logistics.  Examples  are; 

• •  maintenance  support  planning  and  support 

facilities  planning;  other  support  requirements 
determination;  support  equipment;  supply 
support;  packaging,  handling,  storage,  and 
transportation;  provisioning  requirements 
determination  and  planning;  training  system 
requirements  determination;  computer  resource 
determination;  organizational,  intermediate,  and 
depot  maintenance  determination  management;  and 
data  management 

•  (for  ships)  the  Extended  Ship  WBS  (ESWBS) ,  Project 
Management  (897);  Data  Management  (896);  and  Supply 
Support  (853)  elements. 

H.2.3.  Sysbem  Test  and  Evaluation 

The  use  of  prototype,  production,  or  specifically 
fabricated  hardware /software  to  obtain  or  validate 
engineering  data  on  the  performance  of  the  system  during  the 
development  phase  (normally  funded  from  RDT&E)  of  the 
program. 

Includes: 

•  detailed  planning,  conduct,  support,  data  reduction 
and  reports  (excluding  the  Contract  Data 
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Requirements  List  data)  from  such  testing,  and  all 
hardware/ software  items  which  are  consumed  or 
planned  to  be  consumed  in  the  conduct  of  such 
testing 

•  all  effort  associated  with  the  design  and  production 
of  models,  specimens,  fixtures,  and  instrumentation 
in  support  of  the  system  level  test  program 

Note:  Test  articles  which  are  complete  units  (i.e., 

functionally  configured  as  required  by 
specifications)  are  excluded  from  this  vms 
element . 

Excludes : 

•  all  formal  and  informal  testing  up  through  the 
subsystem  level  which  can  be  associated  with  the 
hardware /software  element 

•  acceptance  testing 

Note:  These  excluded  efforts  are  to  be  included  with 

the  appropriate  hardware  or  software  elements. 


H.2.3.1.  Development  Test  and  Evaluation 

This  effort  is  planned,  conducted  and  monitored  by 
the  developing  agency  of  the  DoD  component.  It  includes 
test  and  evaluation  conducted  to: 

•  demonstrate  that  the  engineering  design  and 
development  process  is  complete. 

•  demonstrate  that  the  design  risks  have  been 
minimized. 

•  demonstrate  that  the  system  will  meet 
specifications . 

•  estimate  the  system's  military  utility  when 
introduced. 
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•  determine  whether  the  engineering  design  is 
supportable  (practical,  maintainable,  safe,  etc.) 
for  operational  use. 

•  provide  test  data  with  which  to  examine  and  evaluate 
trade-offs  against  specification  requirements,  life- 
cycle  cost,  and  schedule. 

•  perform  the  logistics  testing  efforts  to  evaluate 
the  achievement  of  supportability  goals,  the 
adequacy  of  the  support  package  for  the  system, 

(e.g.,  deliverable  maintenance  tools,  test 
equipment,  technical  publications,  maintenance 
instructions,  and  personnel  skills  and  training 
requirements ,  etc . ) . 

Includes,  for  example: 

•  all  contractor  in-house  effort 

•  (all  programs,  where  applicable)  models,  tests  and 
associated  simulations  such  as  wind  tunnel,  static, 
drop,  and  fatigue;  integration  ground  tests;  test 
bed  aircraft  and  associated  support;  qualification 
test  and  evaluation,  development  flight  test,  test 
instriamentation,  environmental  tests,  ballistics, 
radiological,  range  and  accuracy  demonstrations, 
test  facility  operations,  test  equipment  (including 
its  support  equipment) ,  chase  and  calibrated  pacer 
aircraft  and  support  thereto,  and  logistics  testing 

•  (for  aircraft)  avionics  integration  test  composed  of 
the  following: 

••  test  bench /laboratory,  including  design, 

acquisition,  and  installation  of  basic  computers 
and  test  equipments  which  will  provide  an 
ability  to  simulate  in  the  laboratory  the 
operational  environment  of  the  avionics 
system/subsystem 

••  air  vehicle  equipment,  consisting  of  the 

avionics  and/or  other  air  vehicle  subsystem 
modules  which  are  required  by  the  bench/ lab  or 
flying  test  bed  in  order  to  provide  a  compatible 
airframe  avionics  system/ subsystem  for 
evaluation  purposes 
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••  flying  test  bed,  including  requirements 

analysis,  design  of  modifications,  lease  or 
purchase  of  test  bed  aircraft,  modification  of 
aircraft,  installation  of  avionics  equipment  and 
instrumentation,  and  checkout  of  an  existing 
aircraft  used  essentially  as  a  flying  avionics 
laboratory 

••  avionics  test  program,  consisting  of  the  effort 
required  to  develop  test  plans /procedures, 
conduct  tests,  and  analyze  hardware  and  software 
test  results  to  verify  the  avionics  equipments' 
operational  capability  and  compatibility  as  an 
integrated  air  vehicle  subsystem 

••  software,  referring  to  the  effort  required  to 
design,  code,  de-bug,  and  document  software 
programs  necessary  to  direct  the  avionics 
integration  test 

(for  engines)  engine  military  qualification  tests 
and  engine  preliminary  flight  rating  tests 

(for  ships)  model  basin,  hydrostatic,  fatigue, 
shock,  special  sea  tests  and  trials,  etc.,  including 
the  Extended  Ship  WBS  (ESWBS) ,  Trials  Agenda 
Preparation,  Data  Collection  &  Analysis  (842) ;  Dock 
and  Sea  Trials  (9823);  and  Hull  Vibration  Survey 
(9825)  elements 


H.2,3.2.  Operational  Test  and  Evaluation 

The  test  and  evaluation  conducted  by  agencies 
other  than  the  developing  command  to  assess  the  prospective 
system's  military  utility,  operational  effectiveness, 
operational  suitability,  logistics  supportability  (including 
compatibility,  inter -operability,  reliability, 
maintainability,  logistic  requirements,  etc.),  cost  of 
ownership,  and  need  for  any  modifications. 
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Includes,  for  example: 


Initial  operational  test  and  evaluation  conducted 
during  the  development  of  a  weapon  system 

such  tests  as  system  demonstration,  flight  tests, 
sea  trials,  mobility  demonstrations,  on-orbit  tests, 
spin  demonstration,  stability  tests,  qualification 
operational  test  and  evaluation,  etc.,  and  support 
thereto,  required  to  prove  the  operational 
capability  of  the  deliverable  system 

contractor  support  (e.g.,  technical  assistance, 
maintenance,  labor,  material,  etc.)  consumed  during 
this  phase  of  testing 

logistics  testing  efforts  to  evaluate  the 
achievement  of  supportability  goals  and  the  adequacy 
of  the  support  for  the  system  (e.g.,  deliverable 
maintenance  tools,  test  equipment,  technical 
publications,  maintenance  instructions,  personnel 
skills  and  training  requirements,  and  software 
support  facility/environment  elements) 


H.2,3.3.  Mock-Ups 

The  design  engineering  and  production  of  system  or 
subsystem  mock-ups  which  have  special  contractual  or 
engineering  significance,  or  which  are  not  required  solely 
for  the  conduct  of  one  of  the  above  elements  of  testing. 


E.2.3.4.  Test  and  Evaluation  Support 

The  support  elements  necessary  to  operate  and 
maintain,  during  test  and  evaluation,  systems  and  subsystems 
which  are  not  consumed  during  the  testing  phase  and  are  not 
allocated  to  a  specific  phase  of  testing. 
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Includes,  for  example: 


•  repairable  spares,  repair  of  repairable,  repair 
parts,  warehousing  and  distribution  of  spares  and 
repair  parts,  test  and  support  equipment,  test  bed 
vehicles,  drones,  surveillance  aircraft,  tracking 
vessels,  contractor  technical  support,  etc. 

Excludes: 

•  operational  and  maintenance  personnel,  consumables, 
special  fixtures,  special  instrumentation,  etc., 
which  are  utilized  and/or  cons^amed  in  a  single 
element  of  testing  and  which  should  be  included 
under  that  element  of  testing 


H.2,3.5.  Test  Facilities 

The  special  test  facilities  required  for 
performance  of  the  various  developmental  tests  necessary  to 
prove  the  design  and  reliability  of  the  system  or  subsystem. 

Includes,  for  example: 

•  test  tank  test  fixtures,  propulsion  test  fixtures, 
white  rooms,  test  chambers,  etc. 

Excludes : 

•  brick  and  mortar-type  facilities  identified  as 
industrial  facilities 

H .  2 . 4 .  Training 

Deliverable  training  services,  devices,  accessories, 
aids,  equipment,  and  parts  used  to  facilitate  instruction 
through  which  personnel  will  learn  to  operate  and  maintain 
the  system  with  maximum  efficiency. 


143 


Includes: 


•  all  effort  associated  with  the  design,  development, 
and  production  of  deliverable  training  equipment  as 
well  as  the  execution  of  training  services 

Excludes: 

•  overall  planning,  management,  and  task  analysis 
function  inherent  in  the  WBS  element  Systems 
Engineering /Program  Management 


H.2.4.1.  Equipment 

Distinctive  deliverable  end  items  of  training 
equipment,  assigned  by  either  a  contractor  or  military 
service,  required  to  meet  specific  training  objectives. 

Includes,  for  example: 

•  operational  trainers,  maintenance  trainers,  and 

other  items  such  as  cutaways,  mock-ups,  and  models 


H.2,4.2.  Services 

Deliverable  services,  accessories,  and  aids 
necessary  to  accomplish  the  objectives  of  training. 

Includes: 

•  training  course  materials;  contractor-conducted 
training  (in-plant  and  service  training);  and  the 
materials  and  curriculum  required  to  design, 
execute,  and  produce  a  contractor  developed  training 
program 

•  materiel,  courses,  and  associated  docxunentation 
(primarily  the  computer  software,  courses  and 
training  aids) 
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Excludes : 


•  deliverable  training  data  associated  with  the  WBS 
element  Support  Data 


H.2,4.3.  Facilities 

The  special  construction  necessary  to  accomplish 
training  objectives. 

Includes,  for  exas^le: 

•  modification  or  rehabilitation  of  existing 
facilities  used  to  accomplish  training  objectives 

Excludes: 

•  installed  equipment  used  to  acquaint  the  trainee 
with  the  system  or  establish  trainee  proficiency 

•  the  brick  and  mortar-type  facilities  identified  as 
industrial  facilities 

H • 2 • 5 •  Data 

The  deliverable  data  required  to  be  listed  on  a 
Contract  Data  Requirements  List,  DD  Form  1423. 

Includes: 

•  only  such  effort  that  can  be  reduced  or  avoided  if 
the  data  item  is  eliminated 

•  (government-peculiar  data)  acquiring,  writing, 
assembling,  reproducing,  packaging  and  shipping  the 
data 

•  transforming  into  government  format,  reproducing  and 
shipping  data  identical  to  that  used  by  the 
contractor  but  in  a  different  format 
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H.2.5.1.  Technical  Publications 

Technical  data,  providing  instructions  for 
installation,  operation,  maintenance,  training,  and  support, 
formatted  into  a  technical  manual .  Data  may  be  presented  in 
any  form  (regardless  of  the  form  or  method  of  recording) , 
Technical  orders  that  meet  the  criteria  of  this  definition 
may  also  be  classified  as  technical  manuals. 

Includes,  for  example : 

•  operation  and  maintenance  instructions,  parts  lists 
or  parts  breakdown,  and  related  technical 
information  or  procedures  exclusive  of 
administrative  procedures 

•  data  item  descriptions  set  forth  in  categories 
selected  from  the  Acquisition  Management  Systems  and 
Data  Requirements  Control  List  (DoD  Regulation 
5010. 12-L) 

•  (for  ships)  Extended  Ship  WBS  (ESWBS) ,  Technical 
Manuals  and  Other  Data  (856)  element 

H.2,5.2.  Engineering  Data 

Recorded  scientific  or  technical  information 
(regardless  of  the  form  or  method  of  recording)  including 
computer  software  documentation.  Engineering  data  defines 
and  documents  an  engineering  design  or  product  configuration 
(sufficient  to  allow  duplication  of  the  original  items)  and 
is  used  to  support  production,  engineering  and  logistics 
activities . 
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Includes,  for  example: 

•  all  final  plans,  procedures,  reports,  and 
documentation  pertaining  to  systems,  subsystems, 
computer  and  computer  resource  programs,  component 
engineering,  operational  testing,  hximan  factors, 
reliability,  availability,  and  maintainability,  and 
other  engineering  analysis,  etc. 

•  Technical  data  package  (reprocurement  package)  which 
includes  all  engineering  drawings,  associated  lists, 
process  descriptions,  and  other  documents  defining 
physical  geometiry,  material  composition,  and 
performance  procedures 

•  (for' ships)  Extended  Ship  WBS  (ESWBS) ,  Design 
Support,  Ship's  Selected  Records  (8302);  Design 
Support,  Services,  Reproduction  (8303);  and 
Engineering  Drawings  and  Specifications  (855) 
elements 

Excludes : 

•  computer  software  or  financial,  administrative,  cost 
or  pricing,  or  management  data  or  other  information 
incidental  to  contract  administration 


H.2.5.3.  Management  Data 

The  data  items  necessary  for  configuration 
management,  cost,  schedule,  contractual  data  management, 
program  management,  etc.,  required  by  the  government  in 
accordance  with  functional  categories  selected  from  the 
DODISS  and  DoD  Regulation  5010. 12-L. 

Includes,  for  exeaaple: 

•  contractor  cost  reports,  cost  performance  reports, 
contract  funds  status  reports,  schedules, 
milestones,  networks,  integrated  support  plans,  etc. 

•  (for  ships)  Extended  Ship  WBS  (ESWBS),  Contract  Data 
Requirements  (988)  element 
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H.2.5.4.  Support  Data 

The  data  items  designed  to  document  support 
planning  in  accordance  with  functional  categories  selected 
from  DoD  Regulation  5010. 12 -L. 

Includes,  for  exar^le: 

•  supply;  general  maintenance  plans  and  reports; 

training  data;  transportation,  handling,  storage, 
and  packaging  information;  facilities  data;  data  to 
support  the  provisioning  process  and  all  other 
support  data;  and  software  supportability  planning 
and  software  support  transition  planning  docxaments. 


H.2.5.5.  Data  Depository 

The  facility  designated  to  act  as  custodian  to 
maintain  a  master  engineering  specification  and  establish  a 
drawing  depository  service  for  government  approved  documents 
that  are  the  property  of  the  U.S.  Government.  As  custodian 
for  the  government,  the  depository,  authorized  by  approved 
change  orders,  maintains  these  master  docxaments  at  the 
latest  approved  revision  level.  This  facility  is  a  distinct 
entity. 

Includes,  for  example: 

•  all  drafting  and  clerical  effort  necessary  to 
maintain  docxaments 

Excludes: 

•  all  similar  effort  for  facility's  specification  and 
drawing  control  system,  in  support  of  its 
engineering  and  production  activities. 
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Note: 


When  documentation  is  called  for  on  a  given  item 
of  data  retained  in  the  depository,  the  charges 
(if  charged  as  direct)  will  be  to  the 
appropriate  data  element. 

H.2.6.  Peculiar  Support  Equipment 

The  design,  development,  and  production  of  those 
deliverable  items  and  associated  software  required  to 
support  and  maintain  the  system  or  portions  of  the  system 
while  the  system  is  not  directly  engaged  in  the  performance 
of  its  mission,  and  which  are  not  common  support  equipment 
(See  H.3.7  below). 

Includes: 

•  vehicles,  equipment,  tools,  etc.,  used  to  fuel, 
service,  transport,  hoist,  repair,  overhaul, 
assemble,  disassemble,  test,  inspect,  or  otherwise 
maintain  mission  equipment 

•  any  production  of  duplicate  or  modified  factory  test 
or  tooling  equipment  delivered  to  the  government  for 
use  in  maintaining  the  system.  (Factory  test  and 
tooling  equipment  initially  used  by  the  contractor 
in  the  production  process  but  subsequently  delivered 
to  the  government  will  be  included  as  cost  of  the 
item  produced.) 

•  any  additional  equipment  or  software  required  to 
maintain  or  modify  the  software  portions  of  the 
system 

Excludes: 

•  overall  planning,  management  and  task  analysis 
functions  inherent  in  the  WBS  element.  Systems 
Engineering/ Program  Management 

•  common  support  equipment,  presently  in  the  DoD 
inventory  or  commercially  available,  bought  by  the 
using  command,  not  by  the  acquiring  command 
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H.2.6.1.  Test  and  Measurement  Equipment 

The  peculiar  or  unique  testing  and  measurement 
equipment  which  allows  an  operator  or  maintenance  function 
to  evaluate  operational  conditions  of  a  system  or  equipment 
by  performing  specific  diagnostics,  screening  or  quality 
assurance  effort  at  an  organizational,  intermediate,  or 
depot  level  of  equipment  support. 

Includes,  for  exarple: 

•  test  measurement  and  diagnostic  equipment,  precision 
measuring  equipment,  automatic  test  equipment, 
manual  test  equipment,  automatic  test  systems,  test 
program  sets,  appropriate  interconnect  devices, 
automated  load  modules,  taps,  and  related  software, 
firmware  and  support  hardware  (power  supply 
equipment,  etc.)  used  at  all  levels  of  maintenance 

•  packages  which  enable  line  or  shop  replaceable 
units,  printed  circuit  boards,  or  similar  items  to 
be  diagnosed  using  automatic  test  equipment 


H.2,6.2.  Support  and  Handling  Equipment 

The  deliverable  tools  and  handling  equipment  used 
for  support  of  the  mission  system. 

Includes,  for  exarple: 

•  ground  support  equipment,  vehicular  support 

equipment,  powered  support  equipment,  nonpowered 
support  equipment,  munitions  material  handling 
equipment,  materiel  handling  equipment,  and  software 
support  equipment  (hardware  and  software) 

H.2.7.  Common  Support  Equipment 

The  items  required  to  support  and  maintain  the  system 
or  portions  of  the  system  while  not  directly  engaged  in  the 
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performance  of  its  mission,  and  which  are  presently  in  the 
DoD  inventory  for  support  of  other  systems. 

Includes: 

•  acquisition  of  additional  quantities  of  this 
equipment  needed  to  support  the  item 

•  all  efforts  required  to  assure  the  availability  of 
this  equipment  to  support  the  item 


H.2 ,7 Test  and  Measurement  E<iuipment 

The  common  testing  and  measurement  equipment  which 


allows  an  operator  or  maintenance  function  to  evaluate 
operational  conditions  of  a  system  or  equipment  by 
performing  specific  diagnostics,  screening  or  quality 
assurance  effort  at  an  organizational,  intermediate,  or 
depot  level  of  equipment  support. 

Includes,  for  exeunple: 

•  test  measurement  and  diagnostic  equipment,  precision 
measuring  equipment,  automatic  test  equipment, 
manual  test  equipment,  automatic  test  systems,  test 

sets,  appropriate  interconnect  devices, 
automated  load  modules,  taps,  and  related  software, 
firmware  and  support  hardware  (power  supply 
6<5uipnisnt,  etc.)  used  at  all  levels  of  maintenance 

•  packages  which  enable  line  or  shop  replaceable 
units,  printed  circuit  boards,  or  similar  items  to 
be  diagnosed  using  automatic  test  equipment 


H.2 .7 ,2 ,  Support  and  Handling  Eguipment 

The  deliverable  tools  and  handling  equipment  used 
for  support  of  the  mission  system. 
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Includes,  for  example: 

•  ground  support  equipment,  vehicular  support 
equipment,  powered  support  equipment,  nonpowered 
support  equipment,  munitions  material  handling 
equipment,  materiel  handling  equipment,  and  software 
support  equipment  (hardware /software) 

H.2.8.  Operatioixal/Site  Activation 

The  real  estate,  construction,  conversion,  utilities, 
and  equipment  to  provide  all  facilities  required  to  house, 
service,  and  launch  prime  mission  equipment  at  the 
organizational  and  intermediate  level. 

Includes: 

•  conversion  of  site,  ship,  or  vehicle 

•  system  assembly,  checkout,  and  installation  (of 
mission  and  support  equipment)  into  site  facility  or 
ship  to  achieve  operational  status 

•  contractor  support  in  relation  to  operational/site 
aestivation 


11.2.8.1.  System  Assembly,  Installation,  and 
Checkout  on  Site 

The  materials  and  services  involved  in  the 
assembly  of  mission  equipment  at  the  site. 

Includes,  for  example: 

•  installation  of  mission  and  support  equipment  in  the 
operations  or  support  facilities  and  complete  system 
checkout  or  shakedown  to  ensure  operational  status. 
(Where  appropriate,  specify  by  site,  ship  or 
vehicle . ) 
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K.2.8.2.  Contractor  Technical  Support 

The  materials  and  services  provided  by  the 
contractor  related  to  activation. 

Includes,  for  example! 

•  repair  of  repairable,  standby  services,  final 
turnover,  etc. 

H.2,8.3.  Site  Construction 

Real  estate,  site  planning  and  preparation, 
construction,  and  other  special-purpose  facilities  necessary 
to  achieve  system  operational  status. 

Includes,  for  example: 

•  construction  of  utilities,  roads,  and 
interconnecting  cabling 

H.2.8.4.  Site/ Ship/Vehicle  Conversion 

The  materials  and  services  required  to  convert 
existing  sites,  ships,  or  vehicles  to  accommodate  the 
mission  equipment  and  selected  support  equipment  directly 
related  to  the  specific  system. 

Includes,  for  example: 

•  operations,  support,  and  other  special  purpose 
(e.g.,  launch)  facilities  conversion  necessary  to 
achieve  system  operational  status.  (Where 
appropriate,  specify  by  site,  ship  or  vehicle.) 

H.2.9.  Industrial  Facilities 

The  construction,  conversion,  or  expansion  of 
industrial  facilities  for  production,  inventory,  and 


153 


contractor  depot  maintenance  required  when  that  service  is 
for  the  specific  system. 


Includes: 

•  equipment  acquisition  or  modernization,  where 
applicable 

•  maintenance  of  these  facilities  or  equipment 

•  industrial  facilities  for  hazardous  waste  management 
to  satisfy  environmental  standards 

H.2,9.1.  Constructxon/Conversion/Expansion 

The  real  estate  and  preparation  of  system  peculiar 
industrial  facilities  for  production,  inventory,  depot 
maintenance,  and  other  related  activities. 

H.2.9,2.  Equipment  Acquisition  or  Modernization 

The  production  equipment  acquisition, 
modernization,  or  transferal  of  equipment  for  the  particular 
system.  (Pertains  to  government  owned  and  leased  equipment 
under  facilities  contract.) 

H.2,9.3,  Maintenance  (Industrial  Facilities) 

The  maintenance,  preservation,  and  repair  of 
industrial  facilities  and  equipment. 

H.2.10.  Initial  Spares  emd  Repair  Parts 

The  deliverable  spare  components,  assemblies  and 
subassemblies  used  for  initial  replacement  purposes  in  the 
materiel  system  equipment  end  item. 

Includes: 
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repairable  spares  and  repair  parts  required  as 
initial  stockage  to  support  and  maintain  newly- 
fielded  systems  or  subsystems  during  the  initial 
phase  of  service,  including  pipeline  and  war  reserve 
quantities,  at  all  levels  of  maintenance  and  support 


Excludes : 


•  development  test  spares  and  spares  provided 
specifically  for  use  during  installation,  assembly,  and 
checkout  on  site.  Lower  level  WBS  elements  should  be  by 
subsystem. 
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APPENDIX  I.  SYSTEMS  ENGINEERING  PROCESS  OVERVIEW 


(Extracted  from  DSMC,  Systems  Engineering  Fundamentals) 

1.1.  THE  PROCESS 

The  Systems  Engineering  Process  (SEP)  is  a 
comprehensive,  iterative  and  recursive  problem  solving 
process,  applied  sequentially  top-down  by  integrated  teams. 
It  transforms  needs  and  requirements  into  a  set  of  system 
product  and  process  descriptions,  generate  information  for 
decision-makers,  and  provides  input  for  the  next  level  of 
development.  The  process  is  applied  sequentially,  one  level 
at  a  time,  adding  additional  detail  and  definition  with  each 
level  of  development.  As  shown  by  Figure  I-l,  the  process 
includes  inputs  and  out-puts,  requirements  analysis, 
functional  analysis  and  allocation,  requirements  loop, 
synthesis,  design  loop,  verification,  and  system  analysis 
and  control . 

1.2.  SE  PROCESS  INPUTS 

Inputs  consist  primarily  of  the  customer's  needs, 
objectives,  requirements  and  project  constraints.  Inputs 
can  include,  but  are  not  restricted  to,  missions,  measures 
of  effectiveness,  environments,  available  technology  base, 
output  requirements  from  prior  application  of  the  systems 
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engineering  process,  program  decision  requirements,  and 
requirements  based  on  "corporate  knowledge." 


Procass  Input 

•  CiJstom0rN«e<bObjeclfV09/ 
Requirem»nt8 

-  Missions 

-  Msssurss  of  EffsctivsnMS 
«  Environmsnts 

ConstTsinfs 

•  Technology  Base 

•  Output  Rsquiremsntt  from  Prior 
OevelopnMmt  Effort 

•  Program  Decision  Requirements  ^ 
■  Requirements  Applied  Through  ^ 

Specifications  and  Standards 


Requirements  Analysis 

•  Analyse  Missions  &  Environments 

•  Identify  Functional  Requiremants 

•  Oefine^firte  Performanee  &  Design 
Constraint  Requirements 

SBvBSS!!!!! 


Requirements  Loop 


Functional  AnalysIs^Allocatlon 

•  Decompose  to  Lower*Level  Functions 

•  Alocate  Performance  A  Other  Limiting  Requirements  to^ 
Al  Functional  Levels 

•  Defoie^efine  Functional  Interfaces  (Intemal^ernaO 

•  Defin^efine/lntegrate  Functional  Architecture 


•  Trade-Off  Studiee 

•  Effectiveness  Analyses 

•  Risk  Management 
Configuration  Management 

•  Interfeoe  Management 

•  Data  Management 
Performanoe  Measurement 

-SEMS 

-TPM 

-  Technical  Reviews 


Design  Loop 


VerHicatlon 


W 


Synthssls 

•  Transform  Ardiitectuies  (Furtetional  to  Physical} 

«  Define  Alternative  System  Concepts,  Configuration 
hems  &  System  Elements 

•  Select  Preferred  Product  &  Procees  Solutione 

•  Define/Reflne  Physical  Interfaces  (Intemal/Extemal) 


Rslatsd  Terms: 

Customer  i 
Primary  Functions « 

Systarm  Elements  > 


Organizations  responsaXe  for  Primary  Funcrk>ns 
Developmsnt,  ProduotioiVConstruclion,  Ve  ifieation, 
DeploymenL  Operations,  Support,  Training,  Disposal 
Hardware,  Software,  Personnel,  Facilities,  Data,  Material, 
Services,  Techniques 


Process  Output 

«  E>evetopment  Level  Dependent 

-  Decision  Date  Beee 
-SystenVConfiguration  Item 

Arohctecture 

-  Specifieations  &  Baselines 


Figure  I.l.  The  Systems  Engineering  Process 


1.3.  REQUIREMENTS  ANALYSIS 

The  first  step  of  the  Systems  Engineering  Process  is  to 
analyze  the  process  inputs.  Requirements  analysis  is  used 
to  develop  functional  and  performance  requirements;  that  is, 
customer  requirements  are  translated  into  a  set  of 
requirements  that  define  what  the  system  must  do  and  how 

s.^ 

well  it  must  perform.  The  systems  engineer  must  ensure  that 
the  requirements  are  understandable,  unambiguous, 
comprehensive,  complete,  and  concise.  Requirements  analysis 
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must  clarify  and  define  functional  requirements  and  design 
constraints.  Functional  requirements  define  quantity  (how 
many) ,  quality  (how  good) ,  coverage  (how  far) ,  time  lines 
(when  and  how  long),  and  availability  (how  often.)  Design 
constraints  define  those  factors  that  limit  design 
flexibility,  such  as  environmental  conditions  or  limits, 
defense  against  internal  or  external  threats,  contract, 
customer  or  regulatory  standards . 

1.4.  FUNCTIONAL  ANALYSIS/ALLOCATZON 

Functions  are  analyzed  by  decomposing  higher-level 
functions  identified  through  requirements  analysis  into 
lower-level  functions.  The  performance  requirements 
associated  with  the  higher  level  are  allocated  to  lower 
functions.  The  result  is  a  description  of  the  product  or 
item  in  terms  of  what  it  does  logically  and  in  terms  of  the 
performance  required.  This  description  is  often  called  the 
functional  architecture  of  the  product  or  item.  Functional 
analysis  and  allocation  allows  for  a  better  understanding  of 
what  the  system  has  to  do,  in  what  ways  it  can  do  it,  and  to 
some  extent,  the  priorities  and  conflicts  associated  with 
lower-level  functions.  It  provides  information  essential  to 
optimizing  physical  solutions.  Key  tools  in  functional 
analysis  and  allocation  are  Functional  Flow  Block  Diagrams, 
Time  Line  Analysis,  and  the  Requirements  Allocation  Sheet. 
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1.5.  REQUIREMENTS  LOOP 

Performance  of  the  functional  analysis  and  allocation 
results  in  a  better  understanding  of  the  requirements  and 
should  prompt  reconsideration  of  the  requirements  analysis. 
Each  function  identified  should  be  traceable  back  to  a 
requirement .  This  iterative  process  of  revisiting 
requirements  analysis  as  a  result  of  functional  analysis  and 
allocation  is  referred  to  as  the  requirements  loop. 

1.6.  DESIGN  SYNTHESIS 

Design  synthesis  is  the  process  of  defining  the  product 
or  item  in  terms  of  the  physical  and  software  elements  which 
together  make  up  and  define  the  item.  The  result  is  often 
referred  to  as  the  physical  architecture.  Each  part  must 
meet  at  least  one  functional  requirement,  and  any  part  may 
support  many  functions.  The  physical  architecture  is  the 
basic  structure  for  generating  the  specifications  and 
baselines . 

1.7.  DESIGN  LOOP 

Similar  to  the  requirements  loop  described  above,  the 
design  loop  is  the  process  of  revisiting  the  functional 
architecture  to  verify  that  the  physical  design  synthesized 
can  perform  the  required  functions  at  required  levels  of 
performance.  The  design  loop  pe2rmits  reconsideration  of  how 


160 


the  system  will  perform  its  mission,  and  this  helps  optimize 
the  synthesized  design. 

1.8.  VERIFICATION 

For  each  application  of  the  system  engineering  process, 
the  solution  will  be  compared  to  the  requirements.  This 
part  of  the  process  is  called  the  verification  loop,  or  more 
commonly.  Verification.  Each  requirement  at  each  level  of 
development  must  be  verifiable.  Baseline  documentation 
developed  during  the  systems  engineering  process  must 
establish  the  method  of  verification  for  each  requirement. 
Appropriate  methods  of  verification  include  examination, 
demonstration,  analysis  (including  modeling  and  simulation) , 
and  testing.  Formal  test  and  evaluation  (both  developmental 
and  operational)  are  important  contributors  to  the 
verification  of  systems. 

1.9.  SYSTEMS  ANALYSIS  AND  CONTROL 

Systems  Analysis  and  Control  include  technical 
management  activities  required  to  measure  progress,  evaluate 
and  select  alternatives,  and  docximent  data  and  decisions. 
These  activities  apply  to  all  steps  of  the  SE  process. 

System  analysis  activities  include  trade-off  studies, 
effectiveness  analyses,  and  design  analyses.  They  evaluate 
alternative  approaches  to  satisfy  technical  requirements  and 
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program  objectives,  and  provide  a  rigorous  quantitative 
basis  for  selecting  performance,  functional,  and  design 
requirements.  Tools  used  to  provide  input  to  analysis 
activities  include  modeling,  simulation,  experimentation, 
and  test.  Control  activities  include  risk  management, 
configuration  management,  data  management,  and  performance- 
based  progress  measurement  including  event  based  scheduling. 
Technical  Performance  Measurement  (TPM) ,  and  technical 
reviews.  The  purpose  of  Systems  Analysis  and  Control  is  to 
ensure  that : 


•  Solution  alternative  decisions  are  made  only  after 
evaluating  the  impact  on  system  effectiveness,  life- 
cycle  resources,  risk,  and  customer  requirements; 

•  Technical  decisions  and  specification  requirements 
are  based  on  systems  engineering  outputs; 

•  Traceability  from  systems  engineering  process  inputs 
to  outputs  is  maintained; 

•  Schedules  for  development  and  delivery  are  mutually 
supportive; 

•  Required  technical  disciplines  are  integrated  into 
the  systems  engineering  effort; 

•  Impacts  of  customer  requirements  on  resulting 
functional  and  performance  requirements  are  examined 
for  validity,  consistency,  desirability,  and 
attainability;  and; 

•  Product  and  process  design  requirements  are  directly 
traceable  to  the  functional  and  performance 
requirements  they  were  designed  to  fulfill,  and  vice 
versa . 
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I. 10.  SE  PROCESS  OUTPUT 

Process  output  is  dependent  on  the  level  of 
development.  It  will  include  the  decision  database,  the 
system  or  configuration  item  architecture,  and  the 
baselines,  including  specifications,  appropriate  to  the 
phase  of  development.  In  general,  it  is  any  data  that 
describes  or  controls  the  product  configuration  or  the 
processes  necessary  to  develop  that  product. 
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